Diğer Tüm Tavsiye Yazılarını Okumuş Yeni Yazılım Geliştiriciler İçin Tavsiye
(buttondown.email)- Kariyerin başında, ünlü geliştirici tavsiyelerini bile olduğu gibi takip etmek yerine önce kendi durumuna uygun olup olmadığını değerlendirmek gerekir; yazılım alanındaki birçok iddianın da güçlü, kesin kanıtları yoktur
- Hoşuna giden fikirleri doğrudan deneyebilirsin, ancak ekip arkadaşlarını aksatmadığın sürece deneme-yanılma yaşamak öğrenme sürecinin bir parçasıdır
Debugging: The 9 Rules, başlangıç seviyesindeki kitapların sıkça boş bıraktığı debugging becerisini ele alan, kolay okunan bir giriş kitabı olarak önerilir- “Doğru yöntem” ya da “best practice” denilen şeyler çoğu zaman belirli başarısızlık örneklerinden ve tarihsel gelişim yollarından doğar; bu yüzden tekniğin kendisiyle yayılma biçimini ayırmak gerekir
- Araçların gizli özelliklerini, diğer departmanların işlerini ve farklı programlama türlerini erken dönemde görmek, sana uygun yazılım işini bulmayı kolaylaştırır
Tavsiyeyi karşılama biçimi
- Geniş kitlelere ulaşan geliştirici tavsiyeleri, yazar çok iyi programcı olduğu için değil, iyi yazdığı için yayılmış da olabilir
- Tüm tavsiyeleri otomatik olarak reddetmek gerekmez, ama kendi durumuna nasıl uygulanacağını dikkatle değerlendirmek gerekir
- Yazılım hakkındaki “nesnel gerçek” iddialarına temkinli yaklaşmak gerekir; bilimsel olarak incelenmiş konu sayısı çok değildir ve araştırma sonuçlarının da genelde net hükümleri yoktur
- “Yanlış şeyler” öğreneceğinden fazla endişe etmene gerek yok
- Birinin fikri hoşuna giderse doğrudan deneyebilirsin
- Ekip arkadaşlarını aktif biçimde aksatmadığın sürece, sonradan farklı yapman gerektiğini düşünsen bile bu süreç sonunda yine öğrenmeye dönüşebilir
- Debugging: The 9 Rules, yeni başlayan geliştiricilere önerilen bir kitaptır
- Okuması kolaydır ve diğer “başlangıç seviyesi programcı” kitaplarının neredeyse hiç ele almadığı önemli bir beceri olan debugging konusunu işler
- Kütüphaneden ödünç almak ya da şirkete satın alma talebinde bulunmak da mümkündür
“Doğru yöntem” ve best practice’lerin sınırları
- Bir noktada programlamanın “Right Way”ini keşfettiğine ve herkes bu yolu izlerse alanın daha iyi olacağına kesin olarak inanabilirsin
- Örnek olarak test güdümlü geliştirme, fonksiyonel programlama, Lisp ve biçimsel yöntemler anılır
- Böyle bir yaklaşıma kapılmaktan tamamen kaçınmak zordur ve hatta keyifli bir deneyim olabilir; ama kimliğini “Right Way Guy” haline getirmemek önemlidir
- Zaman geçince, hangi yöntem olursa olsun programlamanın bunaltıcı ve dağınık olabildiğini; ayrıca o yöntemi kullanmadan da harika yazılımlar üretilebildiğini öğrenirsin
- Birden fazla “Right Way” öğrendikçe, bunları probleme göre karıştırıp kullanabilirsin
- İlk karşılaştığın “Right Way” çoğu zaman o yaklaşıma bütünüyle kapılmış birinden gelir
- Sonradan o kişiyi fazla suçlamamak ve gerçek tekniği, o kişinin onu pazarlama biçimiyle karıştırmamak daha iyidir
- Birçok fikir, saf haliyle bırakılmaktan ziyade başka fikirlerle birlikte kullanılabilmesi için bir miktar uyarlama gerektirir
- Julia Evans’ın dediği gibi, “her best practice’in arkasında bir korku hikâyesi vardır”
- Anlam veremediğin bir best practice varsa, onu doğuran başarısızlık örneğini araştırabilirsin
- O başarısızlık örneği senin durumunla ilgisizse, başka bir yöntemi seçmen de sorun değildir
- Birçok best practice ve yerleşik uygulama yol bağımlıdır
- Bir mentor yaptığı için takip edilen, o mentorun da kendi mentorundan gördüğü için sürdürdüğü bir alışkanlık olabilir
- Geçmişteki bir sorunu çözmek için ortaya çıkan bir yöntem, bugün artık daha az ilgili olabilir
- Sonradan uydurulmuş makul açıklamalar gibi gelen bazı teamüller gerçekten de öyle olabilir; araştırırsan nasıl oluştuklarını geriye dönük izleyebilirsin
Pratik sezgiyi genişletmenin yolları
- Yürüyüş, düşünceleri toparlamaya yardımcı olan bir alışkanlık olarak önerilir
- Kullandığın araçların çoğunda gizli bir derinlik vardır
- Programlama dilleri, Git, JIRA gibi araçların hepsinde uzman seviyesine gelmek gerekmez
- Ama 5-10 dakikalık bir zaman ayırıp başka neler yapabildiklerine bakmak tavsiye edilir
- Şirket içinde diğer departmanlardaki insanlarla konuşmak, işe dair anlayışı genişletir
- Destek, iş alanı, satış gibi ekiplerle konuşabilirsin
- Zamanın varsa ve istemesi kolaysa, onların iş akışını bir süre izlemek de önerilir
- Kariyerin başında mümkünse farklı programlama türlerini deneyimlemek iyidir
- Bunun için mutlaka iş değiştirmek gerekmez; çoğu şirket zaten aynı anda birkaç tür programlama yapar
- Bir web geliştirme şirketindeysen frontend, backend, operasyon ve veritabanı işleri deneyebilirsin
- Bu, öğrenmeye yardımcı olur; ama daha da önemlisi, gerçekten sevdiğin yazılım işini bulma ihtimalini artırır
- İlk işi frontend olduğunda zorlandığını, ama sonra backend’e geçince daha mutlu olduğunu anlatan kişisel bir örnek de yer alır
- Yazılım alanı sürekli değiştiği için, framework modalarına kapılmayıp temel becerilere odaklanma tavsiyesinin bir nedeni vardır
- İnternet, açık kaynak ve konferanslar sayesinde yazılım dünyasındaki bilgiler çok hızlı yayılır
- Fikir paylaşımının önündeki engeller düşük olduğu için, yalnızca bir kişinin kullandığı kişisel bir proje bile birçok kişinin bildiği bir şeymiş gibi görünebilir
- Duyduğun teknolojilerin önemli bir kısmının kullanıcı tabanı küçük olabilir ve geniş çapta benimsenmeyebilir
- İlgin çok güçlüyse erken benimseyen biri olabilirsin; ama değilse birkaç yıl bekleyip gerçekten kalıcı olup olmadığını görmek de sorun değildir
- Hiç kimse geleceği öngöremez; bugünün kendisi de öngörülmesi zor sonuçların ürünüdür
- Elinden gelenin en iyisini yapmak, kendi değerlerine göre yaşamak ve sürecin tadını çıkarmak gerekir
1 yorum
Hacker News yorumları
Yakın zamanda bir hobi projesinde bir junior ve ondan biraz daha az junior olmayan bir geliştiriciyle çalıştım; ikisi de “doğru yol” takıntılıydı
Sadece bizim çalıştıracağımız yaklaşık 300 satırlık bir Discord botu + Rust kodu için eksiksiz dokümantasyon, QA ve “operasyon” için ayrı VM, systemd dağıtımı, birkaç string için şablon sistemi ve dört SQL sorgusu için ORM katmanı istediler
En fazla 10 kişinin kullanacağı bir projeydi ve bu da sadece “0.3” sürüm gereksinimlerinin yarısıydı; ileride daha da aşırı bir tasarım planladıkları için o projeden çekildim
Programlamanın başlarında ben de birkaç yıl böyleydim, ama zamanla bilgisayar biliminde en iyi uygulamalar veya kod stili gibi şeylerin ötesinde çok daha derin konular olduğunu ve sonunda önemli olanın çalışan kod olduğunu öğrendim
Yani asıl sorundan çok küçük ayrıntılara orantısız derecede fazla ilgi göstermek; bunun için de nükleer santral onay kurulunun santrali bırakıp yanındaki bisikletliğin rengini tartışması benzetmesi var
Bu durumda da 10 kullanıcılık bir projede QA/operasyon VM ayrımı, systemd dağıtımı, birkaç string için şablonlama, birkaç SQL için ORM gibi şeylere odaklanmak tipik bir önemsizlik yasası örneği gibi görünüyor
Özellikle junior geliştiriciler bu kısımları anlamakta ve tartışmakta daha rahat olduğu için daha çok müdahil oluyor, buna karşılık zor olan çekirdek özellikler kolayca ihmal ediliyor
Yine de projenin anlamlı kısımlarını düzgün şekilde belgelendirmenin önemsiz şeylere aşırı odaklanmak olduğunu düşünmüyorum
systemd unit yazmak ya da ORM kullanmak sanıldığı kadar zaman almayabilir, ama sonradan birinin projeye bakması veya başka birinin katkı vermeye çalışması durumunda oldukça yardımcı olur
Bağlam hâlâ kafadayken bunları yapmak daha kolaydır; proje büyüdükten sonra bu tür angaryalar neredeyse hiç tamamlanmaz
Hobi projesi olduğu için de belki işi düzgün yaparak araçları öğrenmek ve tatmin olmak istemiş olabilirler
Primerfilminde dört arkadaş yan iş olarak küçük bir bilgisayar şirketi yürütürken, içlerinden ikisi bir SF cihazı yapıyor ve olaylar gelişiyorBaşlarda 50 dolarlık bir router almaları gereken bir sahne var; biri mevcut router'ı tamir etmeyi önerince diğerleri cümle bitmeden neredeyse “denedik” diye cevap veriyor
Birbirlerini çok iyi tanıdıklarını ve birlikte o kadar çok zaman geçirdiklerini, neredeyse zihin okuma seviyesine geldiklerini gösteriyor
Ama biri yeni router satın almaya “yes” deyince, bir başkası “aye demen gerek” diye karşılık veriyor
Yani yan iş karar oylamasında kullanılacak kelimeler konusunda çok katı bir kural var; birbirlerinin cümlesini tamamlayacak kadar yakın olmaları, router'ın 50 dolar olması ya da yan iş gelirinin önemsizliği fark etmiyor
Kural, aye denmesini gerektiriyor
“Doğru yol” takıntılı insanların bir kısmı, toplumsal kolektif zekâya depolanmış bilgiyi kopyalayarak başarılı olmuş ama kendi kafalarının içinde gerçekte ne olup bittiğini pek bilmeyen insanlar gibi geliyor
Kanıtlanmış metodolojileri zahmetle kendileri keşfetmek zorunda kalmama avantajları var, ama o yaklaşımın hangi durumlarda başarısızlığa yol açacağını harfiyen anlayamama gibi bir dezavantajları da var
Yönetmen yorumunda bu sahnenin, bazı karakterlerin kuralları fazla ciddiye aldığını, bazılarınınsa yeterince ciddiye almadığını göstermek için bilerek yerleştirildiği söyleniyor
Bu tür cargo cult tarzı pratikleri başkalarına önermelerinin nedeni de benzer görünüyor: daha fazla kişi bunları uygularsa, o pratik felaketle sonuçlandığında başarısız olan kişinin kendileri olmama ihtimali artıyor
Bugünlerde bunu çok sık görüyorum ve bu insanlara zeki junior diyorum. Kariyerlerinin 1 ya da 20 yıllık olması fark etmiyor
Zeki junior, çoğu tasarım kalıbını bilir ve
Mythical Man-Month'u da okumuştur, ama yeni teknoloji/dil/framework denemek istediği için parlak yeni bir çekici alıp çivi gibi görünen her şeyin peşinden koşarSonra da iyi optimize edilmiş eski bir veritabanının sağlayabileceği gücü anlamadığı için tuhaf kararlar verir
20 yıllık kariyerimde böyle projelerin, orijinal ekibin yarısından fazlası ayrılmışken 5-10 yıl sonra nasıl sona erdiğini çok gördüm; gerçekten değerli kısımları bırakıp gereksiz yarısını kesip atıyorum
Biz ne pahasına olursa olsun eğlenmeye çalışan geliştirici anaokulu işletmiyoruz; para ödeyip istikrarlı ve nispeten hızlı sonuç bekleyen bir işletme için çalışıyoruz
En yeni teknolojiyi kullanmak ya da sıkılmamak için yeni şeyler denemek, uzun vadede düzeltmekten çok bozmakla sonuçlandı
Ekibin tamamının anlayıp ustalaşabileceği teknolojileri devreye almalısınız; sadece sıkılmış bir süperstarın bildiği bir teknolojiyi değil
Özgeçmişinize bol bol teknoloji maddesi eklemek istiyorsanız bunu o tür şirketlerde yapabilirsiniz; onların da kendine göre iyi yanları var
Ama bu insanlar zaten çoğu zaman uzun süre kalmıyor, bu yüzden toplam kattıkları ek değer de şüpheli. Birilerine sıkıcı gelebilir ama ben buna ustalaşmış yaklaşım diyorum
Yan projenin amacı şirketlerin GitHub'ınıza bakmasını sağlamaksa, bu daha da mantıklı görünebilir
Dokümantasyon çok önemlidir. Botlar ve web scraper'lar dahil, 300 satırdan kısa epey basit projelerim var ve dokümantasyon yapmadığım için şimdi çalıştıramıyorum
Üzerinde çalıştıkları Raspberry Pi öldü; headless sanal framebuffer'ı nasıl düzelteceğimi ya da aratsam da işe yarar sonuç çıkmayan bilinmeyen hataları nasıl debug edeceğimi bilmiyorum
Konteynerize etmiş ya da en azından kurulum sürecini belgelemiş olsaydım, bu sorunlar olmazdı
Güzel bir yazı; keşke daha fazla kişi okusa.
Yazılımda, özellikle veri yönetimi alanında 15 yıl çalışarak tam olarak bunu öğrendim.
Theravada Budizmi geçmişimden öğrendiğim Kesamutti Sutta da çok yardımcı oldu.
Mesajı şu: bir şeyi sadece tekrar tekrar duyduğun için, gelenek olduğu için, söylenti olduğu için, kutsal metinlerde geçtiği için, tahmin ya da aksiyom ya da kulağa makul gelen bir mantık olduğu için, uzun zamandır taşınan fikirlere yönelik önyargı nedeniyle, biri yetkin göründüğü için ya da öğretmenin söylediği için olduğu gibi kabul etme.
Bir şeyi ancak kendin “bu iyidir, kınanacak bir şey değildir, bilge kişilerce övülür ve uygulanırsa yarar ve mutluluğa götürür” diye bildiğinde benimsemen yönündeki öğüt, ortaokuldan beri ateist olmama rağmen hayatımda çok faydalı oldu.
Birinin onu daha rasyonalist bir anlama gelecek şekilde çarpıttığını söyleyenler var.
Doğruysa üzücü; çünkü Buddha'nın bu kadar “aydınlanmış” biri olduğuna inanmak isterdim.
https://fakebuddhaquotes.com/do-not-believe-in-anything-simply-because-you-have-heard-it/
“Kandırıldım” ya da “yanlış şeyler öğrendim” diye fazla kaygılanmamak gerektiği kısmına katılıyorum.
TDD popülerken mi öğrendin? Evet. Şimdi TDD kullanıyor muyum? Hayır. Yine de TDD bana daha iyi kod yazmayı öğretti mi? Evet.
Profesyonel olarak artık kullanmadığım diller için de aynısı geçerli. Her şey bir şey öğretir.
İyi orta noktayı bulmak için iki tarafı da biraz aşmadan olmuyor.
Zaten var olan bir kod tabanını genişletmeye çalışıyorsan, kullanım şeklinin çevresine birkaç test yazmak mantıklıdır.
Henüz kod yoksa ama kafanda bir yapı varsa ve önce inşa edip sonra test edebileceğin parçaları ayırabiliyorsan, o zaman da anlamlıdır.
Bu saf anlamıyla TDD değil, daha çok test destekli geliştirme; ama TDD’nin ruhundan yararlanmış oluyorsun.
Kötü şeyler öğrenmek bile hangi yaklaşımın daha iyi ya da daha kötü olduğunu anlamanın büyük bir parçası.
TDD’nin kendisinin kötü olduğunu söylemiyorum ama aşırıya kaçılırsa kötüleşebilir.
Sonuçta bu, “hatalar öğrenmenin yoludur” şeklindeki yaygın düşünceyle de örtüşüyor.
Bu tür yönerge ve ilkeleri genel olarak bilmek iyidir ama insanlar bunları din gibi benimsediğinde sorun çıkıyor.
Sektörümüzdeki ideologlar gerçekten baş belası.
Kısa, yerinde ve hemen oturuyor.
Güzel bir yazı ve iyi tavsiyeler.
Sonunda balayı dönemi bitince, hangi “doğru yolu” kullanırsan kullan programlamanın sinir bozucu ve dağınık olduğunu, ayrıca o yolu izlemeden de harika yazılımlar yapılabildiğini öğreniyorsun.
Zamanla onlarca başka “doğru yol” daha öğreniyor ve bunları probleme göre karıştırıp kullanıyorsun.
Ama son birkaç yılda birçok geliştirici doğru yol takıntısına saplanıp bilgisini ve bakış açısını genişletemiyor gibi görünüyor.
Bu doğruysa üzücü, ama nedenini bilmiyorum.
Belki de bugünlerde kısalan dikkat süresi yüzünden bilgiyi verimli biçimde genişletmek daha zorlaştı ve insanlar bulundukları yerde fazla rahat.
Ya da belki yalnızca belirli bir framework öğrenmeye verilen ödül çok büyük, ama bunun içeride nasıl çalıştığına dair temel bilgiyi öğrenmek için yeterli teşvik yok.
Bu yüzden mevcut işlerinden ders çıkarmaya zaman bulamıyorlar ve o derslerin etkisi ortaya çıkana kadar çoktan ayrılmış oluyorlar.
Aynı anda yeni moda teknolojilere odaklanmamayı da göze alamıyorlar.
Bu akış büyümeyi ciddi biçimde engelliyor.
Benim 1 sentlik tavsiyem şu: durum düşmandır. Mümkün olan her yerde durumu azaltmalısın.
Buna yalnızca kodun içindeki durum değil, iş yapmak için kısa süreli belleğinde tutman gereken şeylerin sayısı ve hatırlaman gereken projeye özgü ayrıntılar da dahil.
Durum düşmandır. Bir şeyi birinci ilkelerden türetebiliyorsan bunu her zaman yapmaya çalışmalısın.
Bunların bir kısmı yalnızca programcılar için verilmiş tavsiyelerin ötesine geçiyor.
İlk madde herkesin üzerinde düşünmeye değer. Birçok yazar ve denemeci, o konuda uzman oldukları için değil, iyi yazdıkları için okunuyor.
Yürüyüşe çıkmak da gerekir.
Farklı türde işler denemek ve şirket içindeki başka rolleri öğrenmek iyi olur.
Özellikle büyük şirketlerde yaptığın iş, bir yerde yeniden düzeltilmesi ya da etrafından dolanılması gereken bir iş olabilir; sen değiştirirsen herkes için daha kolay hale gelebilir.
İlk madde, YouTube gibi video paylaşım servislerinden öğrendiğin şeylere neden şüpheyle yaklaşman gerektiğinin de bir nedeni.
Biri kendinden emin konuşup fikirlerini profesyonelce sunarsa, o fikirler kusurlu olsa bile insanlar onları ciddiye alıyor.
Bazı “denemecilerin” aslında büyük ölçüde Wikipedia yazılarıyla Reddit gönderilerini seslendirdiğinin ortaya çıktığı bir dünyada, ifadenin inandırıcılığıyla doğruluğu birbirinden ayırmaya çalışma tavrı gerekiyor.
10. maddeyi de daha da genişletmek isterim. İlgili insanlarla konuştuğunda, yazılımın ya da geliştirme işinin çözmeye çalıştığı problemin ne olduğunu daha iyi görüyorsun ve kendi başına fark edemeyeceğin acı noktalarını da bulabiliyorsun.
Çok az istisna dışında yazılım, kendisi için değil bir problemi çözmek için yazılır.
İnternette ya da eğitim sürecinin bir yerinde “doğru” cevabı okuyup, gerçekten doğru olup olmadığını düşünmeden kulağa makul gelecek şekilde tekrar edebiliyorlar.
Yazıda önerilen debugging kitabını o kadar sevdim ki birkaç kopya alıp dağıttım.
Arkadaşlarıma, stajyerlere, veri bilimcilere, hatta yöneticilere bile verdim; okuyanların hepsi teşekkür etti.
Büyük teknik sistemlerde sorun çözmek için çok iyi, basit birkaç teknik içeriyor; bu yüzden neredeyse herkes için faydalı.
Okuması kolay ve ilgi çekici; ayrıca kuru olabilecek tavsiyelere renk ve bağlam katan birçok “savaş hikâyesi” de var.
https://debuggingrules.com/
“İnsanlar beni iyi bir programcı olduğum için değil, iyi bir yazar olduğum için dinliyor” sözü, yalnızca iyi yazarların yazdıklarını okurken dikkatli olmak gerektiği anlamına gelmez; işimize yaklaşım biçimimiz için de geçerlidir
İyi yazan insanlar genelde başkalarıyla ilişki kurmakta da iyidir
Yazmak ve iletişim kurmak, yazılım geliştiriciler için işin temel parçalarıdır
Yeni başlayanlara, yaşadıkları zorlukları, denemeleri ve düşünce süreçlerini yazarak kaydetmelerini öneririm
Mümkünse denemeler de yazın. Kariyerin ilerleyen dönemlerinde gerçekten çok işe yarayan bir beceri olur
Yeni başlayanlara düzgünce açıklaması zor bir söz var: “Senin işin kod yazmak değil”
Biz kodu, problemleri çözmek için bir araç olarak kullanırız
Kod, hedefe ulaşmak için bir araçtır; hedefin kendisi değildir
Kodun kendisi için kod yazarsan yanlış sonuçlara varırsın
Problem çözmeye odaklanmalısın; eğer yazdığın kodun hangi problemi çözdüğünden emin değilsen kod yazmayı bırakıp önce bunu anlamalısın
Şirkete göre bu e-posta da olabilir
Soruları yanıtlamak, birlikte çalışmak ve ekibin ya da organizasyonun yönünü etkilemek işin kendisi gibi gelebilir; ama iletişim de kod gibi, yararlı bir şey üretmek için kullanılan bir araçtır, kendi başına yararlı olan şey değildir
Çoğu kodun, hatta “kod için kod” olarak yazılan kodun bile bir problemi çözdüğü söylenebilir
Pek çok programcı da bunu en azından bilinçsizce bildiği için o tür kodları yazar
Asıl sorun, başka insanların — örneğin takım elbiseli iş tarafındaki kişilerin — o kodun başka bir problemi çözmesini istemesidir
Ancak yazılan kodun doğru kod olması gerekir
Daha genel ifadeyle bu, “yazılım sistemlerini uygulayarak iş problemlerini çözmek” diye açıklanabilir
Bunu bir junior geliştiriciye böyle anlatırsan, iş gereksinimlerine odaklanır ve MBA, yönetici ya da PM’lerin söylediklerini eleştirel biçimde değerlendirip doğru işi yapabilir
Ama yatırımcıya satılacak bir yazılıma sahip olmanın kendisi de bir değerdir
Bu yüzden bazen gerçekten kod yazman için para alırsın