Bagaimana cara menjadi pemain tim yang baik? [Tutup]

Saya telah memprogram (secara obsesif) sejak saya berusia 12 tahun. Saya cukup berpengetahuan luas dalam spektrum bahasa di luar sana, mulai dari perakitan, ke C ++, ke Javascript, ke Haskell, Lisp, dan Qi. Tapi semua proyek saya sendiri.

Saya mendapatkan gelar sarjana teknik kimia, bukan CS atau teknik komputer, tetapi untuk pertama kalinya pada musim gugur ini saya akan mengerjakan proyek pemrograman besar dengan orang lain, dan saya tidak tahu cara mempersiapkannya. Saya telah menggunakan Windows sepanjang hidup saya, tetapi proyek ini akan sangat tidak-jadi, jadi saya membeli Mac baru-baru ini dengan harapan membiasakan diri dengan lingkungan.

Saya beruntung berpartisipasi dalam hackathon dengan beberapa teman tahun lalu - keduanya jurusan CS - dan cukup menarik, kami menang. Tetapi saya menyadari ketika saya bekerja dengan mereka bahwa alur kerja mereka sangat berbeda dari saya. Mereka menggunakan Git untuk kontrol versi. Saya belum pernah menggunakannya pada saat itu, tetapi sejak itu saya sudah belajar semua yang saya bisa tentang itu. Mereka juga menggunakan banyak kerangka kerja dan perpustakaan. Saya harus belajar apa Rails cukup semalam untuk hackathon (di sisi lain, mereka tidak tahu apa pelingkupan atau penutupan leksikal). Semua kode kami bekerja dengan baik, tetapi mereka tidak mengerti kode saya, dan saya tidak mengerti kode mereka.

Saya mendengar referensi untuk hal-hal yang dilakukan programmer nyata setiap hari - pengujian unit, ulasan kode, tetapi saya hanya memiliki sedikit pengertian tentang apa ini. Saya biasanya tidak memiliki banyak bug di proyek kecil saya, jadi saya tidak pernah membutuhkan sistem pelacakan bug atau tes untuk mereka.

Dan yang terakhir adalah saya butuh waktu lama untuk memahami kode orang lain. Konvensi penamaan variabel (yang berbeda-beda untuk setiap bahasa baru) sulit (__mzkwpSomRidicAbbrev), dan saya merasa sulit untuk menggunakan kopling longgar. Itu bukan untuk mengatakan saya tidak secara longgar berpasangan - saya pikir saya cukup baik untuk pekerjaan saya sendiri, tetapi ketika saya mengunduh sesuatu seperti kernel Linux atau kode sumber Chromium untuk melihatnya, saya menghabiskan berjam-jam mencoba untuk mencari tahu bagaimana semua direktori dan file aneh ini terhubung. Ini adalah dosa pemrograman untuk menemukan kembali roda, tetapi saya sering menemukan itu lebih cepat untuk menulis fungsionalitas sendiri daripada menghabiskan berjam-jam membedah beberapa perpustakaan.

Jelas, orang-orang yang melakukan ini untuk mencari nafkah tidak memiliki masalah ini, dan saya harus sampai ke titik itu sendiri.

Pertanyaan: Apa saja langkah yang bisa saya ambil untuk mulai "mengintegrasikan" dengan orang lain?

Terima kasih!

Saya pikir Anda sedikit cemas dan bersemangat bekerja untuk sebuah kelompok.

Tidak satu pun dari kami yang belajar bekerja dalam kelompok atau tim dari buku atau diberikan langkah kecil atau "Panduan Dummies untuk Bekerja di Tim".

Kami baru belajar bekerja dengan kelompok dengan bekerja dalam kelompok.

Segala sesuatu yang Anda dengar tentang programmer profesional, akan jatuh ke tempatnya secara bertahap saat Anda bekerja dalam tim .. Anda akan belajar tentang mereka semua satu per satu seperti kontrol versi, pengujian unit dll.

Bagi saya, intinya adalah

Menjadi bagian dari tim.

Saya akan memilih beberapa kalimat Anda dan membuat beberapa poin umum:

(di sisi lain, mereka tidak tahu apa cakupan atau penutupan leksikal). Semua kode kami bekerja dengan baik, tetapi mereka tidak mengerti kode saya, dan saya tidak mengerti kode mereka.

...

Saya mendengar referensi untuk hal-hal yang dilakukan programmer nyata setiap hari - pengujian unit, ulasan kode, tetapi saya hanya memiliki sedikit pengertian tentang apa ini. Saya biasanya tidak memiliki banyak bug di proyek kecil saya, jadi saya tidak pernah membutuhkan sistem pelacakan bug atau tes untuk mereka.

...

Saya menghabiskan waktu berjam-jam untuk mencari tahu bagaimana semua direktori dan file aneh bernama ini terhubung ... Saya sering menemukan itu lebih cepat untuk menulis fungsionalitas sendiri daripada menghabiskan berjam-jam membedah beberapa perpustakaan.

Saya pikir satu hal terbesar yang perlu Anda pelajari adalah ini:

Untuk standar kemampuan pengembang tertentu, tim npengembang melakukan pekerjaan yang kurang dari nyang dilakukan oleh salah satu pengembang sendirian - tetapi mereka masih melakukan lebih dari yang dapat dilakukan oleh satu orang .

Alasannya sederhana: ketika bekerja dengan orang lain, Anda harus meluangkan waktu untuk bertukar informasi dengan orang lain; sedangkan ketika bekerja sendirian, pertukaran informasi semua terjadi di kepala Anda. Yang secara alami lebih cepat.

Hal penting lainnya adalah:

Beberapa rekan kerja Anda akan kurang mampu daripada Anda, tentunya dalam beberapa keterampilan; beberapa bahkan akan kurang mampu daripada Anda dalam semua keterampilan

Dengan mengingat dua gagasan ini, semua yang saya kutip di atas masuk akal. Banyak orang tidak 'mendapatkan' penutupan. Pengujian dan tinjauan kode adalah untuk memastikan kualitas dan mengurangi risiko ketika kode dihasilkan oleh sekelompok orang dengan kemampuan campuran . Pelacakan bug karena ketika Anda menghasilkan sistem yang cukup besar, bug tidak bisa dihindari. Dan perpustakaan tanpa akhir dengan konvensi mereka adalah karena tanpa konvensi ada terlalu banyak kode untuk dipelajari atau ditulis kembali setiap kali Anda membutuhkannya.

Sungguh, saya pikir satu-satunya cara untuk belajar bagaimana bekerja dalam tim adalah dengan benar-benar melakukannya; tapi semoga hal di atas akan membantu Anda mempersiapkan mental. Semoga berhasil!

Cara paling efisien adalah menjadi bagian dari tim.

Bergabung dengan tim mungkin tampak sulit, karena saya mengerti bahwa Anda belum menjadi bagian dari tim, seperti banyak siswa, dan banyak orang yang tugasnya adalah bekerja tanpa ada pengembang lain di sekitarnya.

Saya akan merekomendasikan Anda untuk mengambil bagian dalam proyek open-source yang sangat aktif dan lebih menyukai komunikasi modern saluran terbuka untuk semua (pelacak masalah, milis, wiki, dll). Komunikasi terbuka penting karena Anda mungkin akan mulai dengan mengamati bagaimana orang lain berinteraksi, jadi hindari proyek-proyek yang mengandalkan email antara pengembang inti, atau IRC yang tidak diarsipkan.

Lebih suka proyek yang sepertinya ramah, dengan beberapa kontributor yang cukup sering , daripada proyek dengan 1 orang yang melakukan segalanya. Juga, lebih suka proyek-proyek di mana setiap orang diizinkan untuk menyentuh segala sesuatu (daripada setiap pengembang memiliki area yang dibatasi), karena lebih menyenangkan dan menawarkan lebih banyak peluang untuk komunikasi.

Steker tak tahu malu: Anda sangat disambut di sini !

Saya tidak akan mengulangi apa yang orang lain katakan "just do it" , tetapi saya akan menambahkan poin tambahan yang belum pernah saya sebutkan: seorang manajer yang baik akan sangat membantu Anda berintegrasi ke dalam tim.

Meskipun Anda mungkin memiliki semua hal yang tepat tentang Anda untuk bagian pemrograman pekerjaan, Anda mungkin kehilangan beberapa hal yang lebih terkait dengan pengembangan pribadi dan pengembangan perangkat lunak. Seorang manajer yang baik akan membimbing Anda dalam praktik tim (baik dalam soft skill dan hard skill) untuk membantu Anda berkembang, dan juga diharapkan akan memberi tahu Anda jika Anda telah melakukan, atau melakukan, sesuatu yang bertentangan dengan praktik tersebut; karena Anda tidak dapat memperbaiki sesuatu yang Anda tidak tahu rusak.

Kiat lain yang ingin saya berikan kepada Anda adalah bahwa tidak ada dua tim yang sama, dan bahkan tim yang ada akan berubah ketika satu atau lebih orang bergabung.

Sebuah tim berasal dari interaksi individu yang saling mengenal dan mencoba memahami cara bekerja sama sampai mereka menemukan cara yang sama (lihat misalnya tahap pengembangan kelompok Tuckman ).

Jadi saran saya adalah untuk tidak mencoba dan menemukan jawaban atas pertanyaan Anda sekarang, tetapi untuk melihat apa yang terjadi ketika Anda benar-benar mulai bekerja di tim baru. Beberapa masalah Anda mungkin dianggap bukan masalah oleh kolega Anda, beberapa yang lain akan dianggap relevan dan Anda akan memiliki kemungkinan untuk membahasnya bersama atau bahkan mempromosikan pandangan Anda sendiri tentang topik tersebut. Dan akhirnya, Anda mungkin juga akan berurusan dengan aspek-aspek yang tidak Anda pikirkan.

Saya setuju dengan ElYusubov bahwa Anda membutuhkan banyak kesabaran dan memberikan diri Anda dan kolega baru beberapa tim untuk belajar bekerja bersama sampai Anda menjadi sebuah tim. Jika Anda berlatih olahraga tim, Anda seharusnya sudah mengalaminya.

Satu komentar terakhir tentang menghabiskan banyak waktu memahami kode orang lain. Bekerja dalam tim berarti Anda akan mengerjakan kode orang lain dan pengembang lain akan mengerjakan kode Anda. Terkadang kode terlalu rumit untuk ditulis ulang dari awal. Solusi tipikal adalah meminta pengembang asli untuk meninjau perubahan Anda, sehingga Anda memiliki sedikit lebih percaya diri bahwa Anda tidak melanggar apa pun dalam kode mereka.

Bagi saya ini adalah lompatan besar dalam transisi dari programmer tunggal ke programmer tim: Anda mengerjakan kode yang hanya Anda pahami sebagian dan Anda harus membiasakan diri dengannya. Ini melibatkan lebih banyak komunikasi dengan kolega Anda, banyak rasa hormat (ya, ada konvensi penamaan aneh untuk variabel mereka, lalu apa?) Dan rasa saling percaya (meskipun mereka memiliki gaya pengkodean yang berbeda, saya tahu mereka memberikan kode kerja) .

Menjadi anggota tim yang baik berarti berkomunikasi tanpa rasa takut, mempercayai perguruan tinggi Anda dan mengatasi hambatan dalam proyek sebagai tim dandeliver project as a team.

Butuh waktu , butuh kesabaran dan perlu belajar agar merasa nyaman dan percaya diri sebagai programmer. Juga benar bahwa TIDAK setiap programmer adalah pemain Tim yang baik , dan pemain tim berbagi kesuksesan mereka dan belajar pelajaran dari kegagalan.

Akan sangat membantu untuk menyoroti beberapa karakter anggota tim yang baik .

a) Anggota tim yang baik adalah orang yang berorientasi pada tujuan daripada pada diri sendiri.

b) Kualitas: lebih memikirkan gambaran besar daripada kepuasan diri. Ini adalah poin kunci. Semua kualitas lain (seperti keandalan, komunikasi konstruktif,) mewarisi dari yang ini

c) Cara meningkatkan: Cobalah untuk memenuhi syarat bagaimana Anda berinteraksi dengan tim Anda di siang hari, tentukan poin-poin baik dan buruk, perhatikan mereka selama pertemuan berikutnya. Juga, cobalah untuk Melihat keputusan Tim dari berbagai sudut. Tempatkan diri Anda pada peran orang lain, pikirkan bagaimana Anda dapat memengaruhi pekerjaan orang lain.

Pertama, selamat karena menjadi tipe orang yang tampaknya benar-benar menikmati pemrograman. Namun, pemrograman bukanlah awal dan akhir dari penyampaian sistem yang bermanfaat. Anda akan memiliki tantangan di depan Anda dan itu akan terserah Anda apakah Anda kembali ke program hobi atau melanjutkan karier di mana Anda dapat melakukan apa yang Anda sukai dan mendapatkan bayaran untuk itu.

Anda tidak beruntung karena Anda tidak memiliki pendidikan dalam membangun perangkat lunak. Dalam pendidikan itu ada beberapa hal yang diajarkan (tidak hanya bagaimana memprogram) bahwa untuk lulusan CS dan pengembang perangkat lunak yang berpengalaman akan menjadi kebiasaan. Bukan berarti itu sering muncul di tempat kerja (meskipun pernah untuk saya, sekali) tetapi NP-keras adalah contoh dari istilah yang mereka mungkin mengerti dan Anda mungkin tidak. Anda mungkin tidak memiliki latar belakang teori formal di balik perhitungan, tetapi tidak apa-apa, selama Anda bersedia mempelajarinya. Mungkin master di CS di masa depan Anda? Sepertinya beberapa kode Anda mungkin idiomatis, dalam arti bahwa Anda memiliki gaya pemrograman yang tampak jelas bagi Anda, tetapi tidak bagi yang lain. Perhatikan ulasan kode dan bersedia menerima kritik dan belajar. Ini akan bekerja, dan Anda mungkin frustrasi,

Apa yang Anda miliki untuk Anda sangat berharga. Anda benar-benar tampak menikmati pemrograman. Saya pikir Anda juga akan menikmati aspek-aspek lain dari pengembangan sistem, seperti desain, arsitektur, pengujian, optimasi, dll. Pemrograman adalah salah satu bagian dari teka-teki dan Anda harus belajar keterampilan lain untuk menjadi pengembang perangkat lunak. Selain Hackathons, banyak bisnis yang melibatkan komunikasi, belajar satu sama lain, mendengarkan, dan perencanaan. Saya telah bekerja dengan banyak orang yang lulusan CS dan lebih menyukai pengembangan perangkat lunak daripada menjual mobil atau mengecat rumah, tetapi tidak benar-benar menyukainya.