İşbirlikçi Kodlama Neden En İyi Kariyer Hack'idir?

Programlamaya ilk adımlarınızı atmak, bir yabancı dili öğrenmek gibidir. İlk başta, sözdizimi hiçbir anlam ifade etmiyor, kelime dağarcığı tanıdık değil ve her şey anlaşılmaz görünüyor ve geliyor. Başladığım zamanki gibiyseniz, akıcılık imkansız geliyor.

Yemin ederim öyle değil. Kodlamaya başladığımda, öğrenme eğrisi beni çok etkiledi. Şimdi sahtekarlık sendromu olarak tanıdığım kendimden şüphe duyma hissinden kurtulmaya çalışırken, kendime temelleri öğretmek için on ay harcadım. İşbirlikçi kodlamanın nasıl inanılmaz olanaklar sunduğunu ancak yeni başlayanlar için uygun buluşmalara gitmeye başlayana kadar fark etmedim. Sadece pratik yapmak için doğru insan topluluğuna ihtiyacınız var.

Benim için bu topluluk, kariyerimi metin yazarlığından kodlamaya geçirmeme yardımcı olan ücretsiz JavaScript eğitim kampı olan Kurucular ve Kodlayıcılar'dı. Şimdi bile, kursu tamamladıktan bir yıldan kısa bir süre sonra bile, yazılım geliştirmek için para aldığıma inanamıyorum.

İşbirlikçi kodlama, sorunların üstesinden gelmek ve birlikte çözümler keşfetmekle ilgilidir. Birkaç teknoloji şirketinin görüşme süreçleri sırasında taramak için yeterince ciddiye aldığı ikili programlama gibi teknikleri kapsar. Ayrıca, yaptığınız tek şey evde tek başınıza kodlama yapmaksa öğrenmesi zor olan faydalı becerileri de geliştirir.

İster teknoloji endüstrisinde yeni başlıyor olun, ister birkaç yıllık deneyime sahip olun, işbirlikçi kodlamanın faydası asla bitmez. Bu makalede, bu her zaman yeşil kalan becerilerin sizi yazılım geliştirmede uzun ve başarılı bir kariyer için nasıl donattığına bakacağız.

Mükemmel Eşleştirme

İlk çift programlama deneyimim, Yeni başlayanlar için Herkes İçin Kodlama adlı bir buluşmada oldu. İşte nasıl çalışır: insanlar JavaScript zorluklarını aynı dizüstü bilgisayarda çözmek için genellikle hiç tanışmadıkları insanlarla eşleşir. Bir kişi 'navigatör' rolünü üstlenir ve yazılması gerektiğini düşündüğü kodu önerir. Diğer kişi, 'sürücü', önerilerini dizüstü bilgisayara yazar ve net olmayan bir şey olduğunda sorular sorar. Bunu yapmaya devam edersiniz, iki saatlik oturumun sonuna kadar sık ​​sık rol değiştirirsiniz.

Teoride, basitti. Pratikte, pek değil.

Yazarken tanımadığım birinin ekranımı izlemesini oldukça rahatsız edici buldum ve rolleri değiştirme zamanı geldiğinde kontrolü devretmek konusunda isteksizdim. Navigasyonu daha da zor buldum. Bir fikir, önce eşinizin ellerinden geçmeden kafanızdan bilgisayara geçemediğinde, söylediğiniz her kelime önemlidir. İkimizden de alışık olmadığımız bir düzeyde iletişim gerektiriyordu ve ayrı ayrı çalışmak için ayrılırsak ikimizin de daha çok şey öğreneceğinden emindim.

Neyse ki, onunla kaldık; Ertesi hafta tekrar buluşmaya gittim. O zamandan beri düzinelerce geliştiriciyle yüzlerce saat geçirdim ve başlangıçta mümkün olduğunu düşündüğümden daha fazlasını öğrendim.

Eşli programlama, öğrenmenin inanılmaz derecede hızlı bir yoludur. Yöntemin büyüsü - başlangıçtaki garipliği bir kez aştığınızda - hemen sonuç vermesidir. Borsadaki baloncuklar gibi bazı geri bildirim döngülerinin bir düzeltme üretmesi saatler, günler hatta aylar alabilir. Çift programlama saniyeler değilse de dakikalar alır. Noktalı virgülü yanlış yerleştirdiğinizde, iki çift göz, hatayı bir çift gözden daha hızlı görebilir. Hileli bir hata mesajıyla ilgili ipuçları için StackOverflow'u aramanız mı gerekiyor? Siz ve eşiniz, bir cevap bulmak için gereken süreyi yarıya indirerek, farklı konuları okuyabilirsiniz.

Daha da zor problemler için, mafya programlaması daha ileri bir adım olabilir. Bu yöntem, bir kişinin yazarken aynı bilgisayar ekranı ve beyin fırtınası çözümleri etrafında gerçek zamanlı olarak beyin fırtınası yapmak için bir ekibin çapraz işlevli bir bölümünü gerektirir.

"Aynı şey üzerinde, aynı zamanda, aynı alanda, aynı bilgisayarda çalışan tüm parlak beyinler."

— Woody Zuill, Çevik Koç ve Çete Programlama Eğitmeni

Çalışmak için verimsiz bir yol gibi görünse de, Woody Zuill gibi mafya programlama savunucuları, herkesin kodu yazılırken gerçek zamanlı olarak gözden geçirmesi nedeniyle bireysel kod incelemelerine olan ihtiyacı ortadan kaldırarak zamandan tasarruf sağlayabileceğini söylüyor. Verimlilik bir yana, bence mobbing sadece kod hakkında değil, diğer insanların sorunlara nasıl yaklaştığını öğrenmenin harika bir yolu. Eşli programlama, maruz kaldığınız bakış açılarının sayısını iki katına çıkarırsa, mafya programlama daha da fazla içgörü sağlar.

Bu, eşleştirmenin - ya da gerçekten mobbingin - düz yelkencilik olduğu anlamına gelmez. Başlangıçta zorlandığım bir şey, aptalca gelebileceğini düşündüğüm sorular sormak için egomu bir kenara koymaktı. Bu durumlarda, özellikle ikiniz de yeni başlıyorsanız, eşinizin aynı düşüncelere sahip olabileceğini hatırlamakta fayda var.

Kendinizi daha kıdemli biriyle eşleşirken, belki de işte bulursanız, onların beyinlerini seçmekten ve merakınızla onları etkilemekten korkmayın. Sizden sadece biraz daha ileride olan biri bile, daha kıdemli birinin aklına gelmeyecek şeyleri düşünebilir. Favori eş programcılarımdan bazıları benden sadece birkaç ay daha fazla deneyime sahipler, ancak her zaman tam olarak hangi hataları yapacağımı ve beni doğru yöne nasıl yönlendireceklerini biliyorlar. Bu geliştiriciler, aptalca bir soru diye bir şey olmadığını söylediklerinde, gerçekten ciddidirler. En iyi ikili programcılar, harika görünmeye gerek kalmadan veya aptal görünme korkusu olmadan özgürce konuşurlar.

Eşli programlama pratik gerektirir, ancak mükemmelleştirmeye değer. Araştırmalar, sorunları çözmek için bir araya gelen programcıların daha özgüvenli, üretken ve işlerine daha bağlı olduklarını gösteriyor. İster bir sonraki işinizi arıyor olun, ister yeni işe alımlar yapıyor olun, eşleştirme önemlidir.

Kaynaklar ve İleri Okuma

• “Çift Programlama Rolleri,” Jordan Poulton, GitHub
• "Google'ı Devasa Yapan Dostluk" James Somers, The New Yorker
• “Mob Programlama: Tüm Ekip Yaklaşımı,” Woody Zuill, YouTube

Mühendislik Empatisi

Kendime JavaScript öğretmeye başladığımda, kodum yatak odamın zeminine çok benziyordu: Toparlamaktan başka seçeneğim kalmayana kadar daha da dağınık olmasına izin verirdim. Web tarayıcım bunu anlayabildiği sürece, nasıl göründüğü umurumda değildi.

Diğer insanların kodunu incelemeye başlayana kadar, benimkini inceleyen insanlara daha fazla empati göstermem gerektiğini fark ettim.

Empati, herhangi bir geliştiricinin cephaneliğinde en az değer verilen araç olabilir. IDEO'nun kullanıcı araştırmasını tasarım sürecinin merkezine koymasının ve Etsy'nin tasarımcılarından ve ürün yöneticilerinden mühendislik rotasyonu yapmalarını istemesinin nedeni budur. Empati, işimizin diğer insanları nasıl etkilediğini görme fırsatımız olduğunda ortaya çıkar. İşbirlikçi kodlamanın onu oluşturmanın harika bir yolu olmasına şaşmamalı.

Akran kod incelemesi - birbirimizin kodunu hatalar için kontrol etme eylemi - bizi empati kurmaya çağırıyor. Gözden geçiren kişi olarak, birinin eleştirmek üzere olduğunuz kodu yazmak için büyük çaba sarf ettiğini bilmek önemlidir. Bu nedenle, yargılamayı ima edebilecek veya çalışmalarını önemsizleştirebilecek ifadeler kullanmaktan kaçının. Kodlarına başvurduğunuzda, onlara hakkında sorularınız olan belirli işlevleri ve satırları göstermek ve bunu nasıl yeniden düzenleyebileceklerini önermek istersiniz. Öğrenme kaynaklarını paylaşmak, bir çözümü kaşıkla beslemekten daha yararlı olabilir. Kod incelemelerinden aldığım en faydalı geri bildirimlerden bazıları eğitici makaleler, videolar ve hatta podcast önerileri şeklinde geldi.

Kodunuz için iyi belgeler yazmak da uzun bir yol kat eder. Net kurulum talimatlarıyla benioku oluşturmak kadar basit bir işlem, kodunuzla çalışması gereken herkes için empati gösterir. GitHub'ın kurucusu Tom Preston-Werner, geliştirme için önce beni oku yaklaşımını savunuyor.

“Yanlış spesifikasyonun mükemmel bir şekilde uygulanması değersizdir. Aynı prensibe göre, güzelce hazırlanmış, hiçbir belge içermeyen bir kitaplık da neredeyse değersizdir. Yazılımınız yanlış sorunu çözüyorsa veya kimse onu nasıl kullanacağını çözemiyorsa, çok kötü bir şey oluyor demektir.”

— Tom Preston-Werner, GitHub Kurucusu

Belgeleri başarılı işe alım sürecinin önemli bir parçası olarak gören teknoloji kurucularıyla da konuştum. Bir CTO, genç bir geliştirici ekibine katıldıktan sonraki altı ay içinde bir üretkenlik düzeyine ulaşmakta zorlanıyorsa, bunun kod tabanının yeterince iyi belgelenmediğine işaret ettiğini söyledi. Yazdığınız karmaşık bir işleve açıklayıcı bir yorum eklemek yalnızca birkaç saniye sürer, ancak ekibinize katılan bir sonraki kişiyi saatlerce çaba harcamaktan kurtarabilir.

Kaynaklar ve İleri Okuma

• "Empati ve Çekme Talepleri Üzerine", Slack Engineering, Medium
• “Beni Okumaya Dayalı Geliştirme,” Tom Preston-Werner, GitHub
• The New York Times Magazine'den Charles Duhigg, "Google'ın Mükemmel Ekibi Kurma Arayışından Öğrendikleri"

Çevik Başarı

CGI filmleri yapmak için harcanan milyonlarca çalışma saatinden, büyük bütçeli video oyunlarının piyasaya sürülmesine yol açan yoğun geliştirme çalışmalarına kadar, yüksek teknik başarılar akıllara durgunluk veren bir çaba gerektirir. Şu anki işverenimin kod tabanını ilk gördüğümde, tüm bunların muazzamlığı karşısında şaşkına dönmüştüm. Bunu nasıl biri inşa etti?

Cevap, doğru işbirlikçi çerçeve verildiğinde, herkesin herkesten çok daha fazlasını inşa edebileceğidir. İşbirliğine dayalı kodlamayı teşvik eden şirketlerde yazılım, yalnız bir dehanın çabalarıyla ortaya çıkmaz. Bunun yerine, harika ekiplerin harika işler çıkarmasına yardımcı olan birlikte çalışmanın yolları vardır. Founders and Coders'daki geliştiriciler, 'Çevik' olarak bilinen popüler bir yazılım geliştirme metodolojisi uygularlar ve benim deneyimime göre, işlevler arası geliştirme ekiplerine 'işlevsel' olanı koyar.

Çevik hakkında tüm kitaplar yazılmıştır, ancak burada temel kavramların bir özeti verilmiştir:

• Bir ürün geliştirme ekibi, büyük çalışmaları 'kullanıcı hikayeleri' adı verilen küçük birimlere ayırır, bunlara öncelik verir ve 'sprint' adı verilen iki haftalık döngüler halinde teslim eder.
• Proje devam ettiği sürece döngüler tekrar eder ve yeni ürün gereksinimleri gelecekteki sprintler için birikmiş görev listesine eklenir.
• Ekip, ilerlemelerini tartışmak ve engelleyicileri ele almak için günlük stand-up toplantıları düzenler.
• Süreç hem artımlı hem de yinelemelidir: yazılım parçalar halinde oluşturulur ve teslim edilir ve ardışık sprintlerde iyileştirilir.

Kişisel hobi projeleri genellikle 'özellik sürünmesi'ne yenik düşen kronik bir tamirci olarak, hiç kimsenin kullanmadığı şeyleri inşa etmek için zaman harcamanın ne kadar kolay olduğunu biliyorum. Tüm ekibin, kullanıcılarınızın gerçekten önemsediği özellikleri sunmaya odaklanabilmesi için Agile'ın sizi kullanıcı hikayelerine öncelik vermeye zorlama şeklini seviyorum. Üzerinde çalışmayı bitirdikten sonra da yaşamını sürdürecek bir ürün veya hizmet oluşturma ortak hedefi etrafında birleştiğinizi bilmek motive edicidir.

Görevleri küçük kullanıcı hikayelerine bölmek, programlama oturumlarını zaman kutusuyla eşleştirmenin harika bir yolu olabilir. Kendinizi ne kadar derinde bulursanız bulunun, önemli bir özellik üzerinde çalışmayı bitirmek, masalarınızdan uzaklaşmak ve bir mola vermek için her zaman güzel bir hatırlatmadır. Çevik, aksi takdirde eksik olabileceği işbirlikçi kodlamaya yapı kazandırır.

Bu arada, günlük stand-up'lar size sizi engelleyen herhangi bir şey hakkında konuşma özgürlüğü verir ve sprint retrospektifleri, önemli kazanımları paylaşmak ve takımın nerede gelişebileceğini belirlemek için alan sağlar. Bu törenler bir işbirliği ve sorumluluk duygusu geliştirir ve birlikte kendi başımıza öğrenebileceğimizden daha fazlasını öğrenmemize yardımcı olur.

Tüm bu Çevik ilkeleri uygulamaya koymak, özellikle ekipteki hiç kimse bu şekilde çalışmaya alışık olmadığında zor olabilir. Founders and Coders'da çoğu öğrencinin günlük stand-up yapma alışkanlığı kazanması biraz zaman alır. Ancak, 18 haftalık proje tabanlı uygulamadan sonra, süreçlerinizin ve iletişim becerilerinizin son derece geliştiğini görüyorsunuz. İlk müşteri çalışmanızı üstlendiğinizde, bir ekipte tam yığın bir web uygulaması oluşturmaya nasıl yaklaşacağınıza dair çok daha net bir zihinsel model oluşturdunuz.

Çevik öğrenmenin en iyi yolu, diğer insanlarla ilginç projeler inşa etmektir. Hackathonlara katılmak, potansiyel ortak çalışanlarla bağlantı kurmanın mükemmel bir yoludur. Birçok açık kaynaklı proje, kanban proje panolarını herkese açık hale getirir, böylece farklı katkıda bulunanların hangi GitHub sorunları üzerinde çalıştığını görebilirsiniz. Yeni başlayanlardan birkaç hoşgeldin katkısı ve sık sık kendinizi açık konulara atayabilir ve çekme talepleri oluşturmaya başlayabilirsiniz.

Çoğu teknoloji şirketi bir çeşit Çevikliğe abone olduğundan, işverenlerin röportajlarda bunu sorması nadir değildir. Sahip olduğunuz herhangi bir deneyim, sizi Agile'ı göz önünde bulundurarak, işbirliği içinde kodlama yapmamış olabilecek diğer adaylardan ayırabilir.

Kaynaklar ve İleri Okuma

• "Çevik Nedir?", Steve Denning, Forbes
• “Agile'ı Kucaklamak,” Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi, Harvard Business Review
• Deloitte Digital'den Shmavon Gazanchyan "Müthiş İlk Çekme Talebi Fırsatları"

Uzaktan İşbirliğine Dayalı Kodlama Aracı Önerileri

Son birkaç yılda, uzaktan çalışma araçları, Gatsby ve Zapier gibi önde gelen şirketlerin artık “önce uzaktan” olduğu noktaya geldi. Bunun bir trende dönüşüp dönüşmeyeceğini görmek için kalırken, uzaktan geliştirme ekiplerinin kalıcı olduğunu söylemek güvenli.

Bu ruhla, size ve ekibinize uzaktan işbirliği içinde kod yazmanıza yardımcı olabilecek bazı araçlar:

Bu makaleyi okumaktan bir şey alırsanız, takım oyuncularının bireysel katkıda bulunanları geride bırakmasını istiyorum. Her iki haftada bir ustalaşmak için yeni ve sıcak bir çerçevenin olduğu bir alanda, teknik becerilerimiz, yumuşak becerilerimizin yaşamayacağı şekilde yaşlanıyor. Sonuç olarak, diğer insanlarla iyi çalışabilen geliştiriciler, yeteneklerinin her zaman talep edildiğini göreceklerdir. İşbirliğine dayalı kodlama, yalnızca öğrenmenin etkili bir yolu değildir; herkesin yeterli pratik ve sabırla geliştirebileceği, aranan bir beceri setidir.