Yazılım Mühendisi Olmak İçin Hangi Beceriler Üzerinde Çalışmanız Gerekiyor?
Son altı yılımı teknoloji alanında, bunun 5 yılını üniversitede ve ancak son zamanlarımı tam zamanlı bir yazılım mühendisi olarak geçirdim. Ancak bu süre zarfında, sürekli değişen teknoloji dünyasında “kıdemli” olmanın ne anlama geldiğini gösteren sınıf arkadaşlarının, iş arkadaşlarının ve yöneticilerin özelliklerini gördüm. Kıdemli bir yazılım mühendisinin yüz değerinin görüntüsü, bilgisayarlarının başına oturdukları ve tam bir sprintte tam bir ürünü öğüttükleri “10x kodlayıcı” yı andırır.
İnanın gerçeği söylüyorum. Aslında, kolejde parlak, ancak iletişim gibi becerilerden ve ayaklarına gelen fırsatları ciddi şekilde engelleyen, eleştirileri kabul etme gibi becerilerden yoksun olan birçok öğrenci tanıyordum. En iyi şirketlerde işe alınan ya da kolejden hemen sonra üst düzey pozisyonlara gelen öğrenciler, yaptıkları işte kesinlikle yetenekliydiler, ancak onları gerçekten diğerlerinden ayıran şey, başkalarıyla iş birliği yapma yetenekleriydi.
Bu Bir Şans Meselesi Değil
İş birliği yeteneği yalnızca akademiden sonra güçlenir. Biletleri ve özellikleri üretebilen ancak bunu kendine saklayan yazılım mühendisi nadiren terfi ettirilir. Bilgiyi paylaşmayı ve ekiplerini yükseltmeyi öğrenenler liderlik pozisyonlarına yerleştirilmeye daha yakındır. Bu şans meselesi değildir, yazılım mühendisliğinde başkalarına liderlik etmenize ve onların gelişmesine katkı sağlamanıza izin veren çok özel ve somut beceriler vardır, bu da kıdemli olmak demektir.
Öyleyse, sizin kıdemli bir yazılım mühendisi olmak için ihtiyaç duyduğunuz becerilerin listesine geçelim.
1. Sahiplenme
Liderlerin hayattaki en temel yönlerinden biri, sürekli sahiplenme pratiğidir.Extreme Ownership kitabında, emekli ABD Donanması Özel Kuvvetler Subayı Jocko Willink, ABD Deniz Kuvvetleri SEAL ekiplerinde 20 yıla aşkın dersler veriyor. Kitapta Jocko, bir takımın ya da bir şirketin başarılı olup olmayacağı konusunda nihai faktör olan liderlerin hikayelerini anlatıyor.
“Aşırı Sahiplenmenin kalbindeki en temel ve önemli gerçekler: Kötü takımlar yoktur, sadece kötü liderler vardır.” — Jocko Willink
Aşırı sahiplenme uygulayanlar için rutin uygulamalar, ekibin başarılı olup olmamasına bakılmaksızın her zaman sorumluluğu üstüne almaktır. Bağlayıcı olduğu kadar özgürleştirici de yoğun bir paradigma değişimidir, çünkü aşırı sahiplendiğinizde, başkalarını suçlamak bir seçenek değildir, her şeyin sorumlusu siz olursunuz.
Tecrübesiz bir mühendis bir bilet için kabul kriterlerini karşılamıyorsa, bunun nedeni lider olarak sizin bunu açıklamak ve anlaşıldığından emin olmak için zaman ayırmamış olmanızdır. Takım arkadaşlarınızdan biriyle iletişim kurmak zorsa, bunun nedeni ne zaman müsait olacağınızı ve ne sıklıkla iletişimin gerekli olduğunu netleştirmemiş olmanızdır.
Hatalı bir kod üretime geçerse, bunun nedeni bu kodun incelemesini değerlendirmek için yeterli zaman ayırmamış olmanızdır. Kıdemli bir yazılım mühendisi olmak, tamamen, sizin, neyi kontrol edebileceğinize odaklanmak ve bu gücü, başkalarını, daha yüksek bir seviyeye yükseltmek için kullanmakla ilgilidir.
2. İletişim
Evet, kariyerinizde nasıl başarılı olacağınızı anlatan herhangi bir makalede en çok üstünde durulan beceri noktasına ulaştınız. Ancak bu konuda her yerde söz ediliyorsa, neden sürekli onu geliştirmeye çalışmıyorsunuz? Şirketler tamamen uzaktan çalışmaya geçtiğinden beri teknoloji alanı radikal bir değişile karşı karşıya. Kıdemli bir mühendis olmak için iletişim becerilerinizi geliştirmek şimdi her zamankinden daha önemli. İletişim becerilerinizi geliştirmenin ilk adımı, yazınızı açık ve yalın tutmaktır.
Özellikle mühendislik bağlamında, düşüncelerinizi metin üzerinden bir başkasına ifade etmek şaşırtıcı derecede zor oluyor. Slack gibi kanallar üzerinden iletişiminiz üzerinde aktif olarak çalışabilirsiniz, ancak mesajlarınızdan sonra “bu mantıklı mı?” ya da “Bunu ifade etmenin daha iyi bir yolu var mı?” gibi mesajlar görebilirsiniz. Takım arkadaşlarınız, herkesin hayatını kolaylaştırdığı için geri bildirim vermekten mutluluk duymalıdır. İletişiminizi geliştirmek için benim yaptığım gibi bir Blog’ta yazı yazabilirsin.
İletişiminizi geliştirmek için başka bir ipucu da aşırı iletişim kurmaktır. İş arkadaşlarınıza spam göndermek istemezsiniz, ancak ayrıntıları dışarıda bırakmaktansa her zaman fazla açıklama yapmakta yarar vardır.
İşte bir örnek:
Hey, bu hatayı düzeltmek için değişiklikleri yaptım. Ne düşündüğünü söyler misin?
Ya da,
Günaydın, A projesindeki testlerimizden birinin neden başarısız olmaya devam ettiğini görememe sorununu çözdüm. Daha kolay hata ayıklayabilmemiz için yöntemlerimize hata çevrim türleri ekledim ve go rutinlerimizi bekleyecek kadar kanal oluşturmadığımızı gördüm. Herhangi bir öneriniz olması durumunda, birleştirme isteğimin bağlantısını burada bulabilirsiniz.
İletişim kurma yeteneğinizi geliştirmek, bir ekibe liderlik edebilecek kişilerin yapması gereken önemli bir pratiktir.
3.Egonuzdan Kurtulun
Kimse Gilfoyle gibi biriyle çalışmak istemez. Her şeyi kendi başına çözebilen 10x kodlayıcı fikri tamamen abartılıyor. Böyle bir mühendis bir şirketten ayrıldığı anda, diğer mühendisler “test gerektirmeyen” kodu bulmaya çalıştıkça büyük bilgi boşlukları olması çok muhtemeldir.
Bunun yerine, büyük bir lider her zaman başkalarından bir şeyler öğrenmek için kendini alçaltabilir. Takım arkadaşlarınızdan biri size, süslü özel testlerinizin yaptığı her şeyi standart ve yeniden kullanılabilir bir şekilde yapan yeni bir test çerçevesi olduğunu söylerse, kodunuzu savunmayın ve bunun yerine takımı daha iyi hale getirdiği için takım arkadaşınıza teşekkür edin. Bu senin kodunla ilgili değil, takımın koduyla ilgili.
Cidden, bir iş arkadaşınızın kodunu daha iyi hale getirmenin yollarını bulursanız, kod incelemesine bir yorum bırakın! Sadece şikâyet etmek kimseye bir şey kazandırmaz. Kıdemli bir mühendis olmak istiyorsanız, takım arkadaşlarınızı aptal değil, öğreniyormuş gibi hissettirin.
4. O Muhteşem Belgeleri Nasıl Yazacağınızı Öğrenin
Hiç “kod kendi kendini belgelemeli” ifadesini duydunuz mu? Tamamen yanlış değil, ama aynı zamanda doğru olmaktan da çok uzak. Her zaman temiz ve özlü kod yazmaya çalışmalısınız, ancak bazen bir yorum bırakmanız gerekecek. Ayrıca yeni API’nizle nasıl çalışacağınızı belgelemeniz gerekir. Yeni ürününüzün herhangi bir mimari belgesi yoksa, gereksinimler değiştiğinde, bunun sizi ne kadar ileri taşıyabileceğini görün.
Belgeleme becerilerinizi geliştirmenin birçok yolu vardır, özellikle de bilet takibi için Jira veya program akış diyagramları oluşturmak için Confluence gibi yazılımlar kullanıyorsanız. Kendi ekibinizdeki kıdemli mühendislerin mimarilerini nasıl belgelediklerini incelemek, en iyi uygulamaları öğrenmenize olanak sağlayacaktır.
Ek olarak, daha iyi tanımlanmış biletler oluşturmak istiyorsanız, 5n1k’ya odaklanmanız gerekir. Kendinize sormanız ve ardından bilet belgelerinize yanıtlamanız gereken genel sorular, bu değişikliğe neden ihtiyacımız var?
Bu değişiklikler hangi projelerde gerçekleşecek? Bu değişikliği oluşturmak için üst düzey teknik adımlar nelerdir? Daha iyi akış şemaları oluşturmak da çok önemlidir. Hızlı bir ipucu, mantığınızda soldan sağa hareket ederken akış şemalarınızın yollarını bölmektir. Bu, açık bir yolu olmayan büyük bir mantık karmaşası yaratabilen karar sembollerine kıyasla, takip edilmesi çok daha kolay bir diyagram oluşturur.
5.Yazılım Geliştirme İlkeleri
Kıdemli bir yazılım mühendisi olacaksanız, alet çantanızı bilmeniz gerekir. Bu mühendislerin kodlama sihirbazı olmaları gerekmez, ancak beceri setlerinde kapsamlı olmaları gerekir. İşte öğrenmeniz gereken bazı teknik noktalar şunlardır:
- Test Etme: Neyse ki, bu standart hale geliyor. Aslında, bir iş görüşmesinde şirketin test yapmadığını fark ederseniz, bunu kırmızı bayrak olarak görmelisiniz. Test etme, beklediğiniz gibi davranan kod yazmanıza, kendi kendini belgelemeye ve bir şeyi kırmaktan korkmadan kodunuzu geliştirmenize olanak tanır.
- Tasarım Desenleri: Bu benim kişisel favorim.Tasarım kalıpları, iş gereksinimlerini karşılayan belirli davranışları işlemek için size bir temel yapı sağlar.Bir sosyal medya platformu mu oluşturuyorsunuz? Gözlemci modeli sizin için iyi bir başlangıç olacaktır. Hataya dayanıklı bir kullanıcı arayüzü oluşturmak ister misiniz? Sonlu durum makinesi kullanın. Go’da tasarım kalıpları hakkında çok şey yazıyorum ve bunlar daha yetkin bir yazılım mühendisi olmanın hızlı bir yolu.
- Çerçeveler: Ortak bir görev gibi görünen bir kod yazıyorsanız, muhtemelen bunun için bir çerçeve vardır. Üst düzey bir mühendisin, herhangi birinin kullanımdan kaldırılıp kaldırılmadığını veya halihazırda kullanmakta olduğunuzdan daha iyi bir çözüm olup olmadığını bilmek için en son çerçevelerde güncel olması önemlidir.
Bu makaleyi teknik bir dille yazdık, ancak bu ilkelerin ayrıntıları sürekli değişeceği için çok önemli değil. Kıdemli bir yazılım mühendisi olmak için gereken çok şey var, ancak günün sonunda gerçekten kendi kendine öğrenme, sahiplenme ve her zaman ekibin iyileştirilmesine odaklanma yeteneğinize bağlı. Birlikte çalıştığım en iyi programcılar, bilgileri paylaşmaktan ve beni daha iyi hale getirmekten her zaman mutlu olanlardı, böylece kendilerini ve ekibi bir bütün olarak süreçte daha iyi hale getirdiler.
