Bir Teknoloji Lideri Olarak Öğrendiğim Şaşırtıcı Dersler

Herkese merhaba! Bir süre yazmadan uzak kaldıktan sonra geri döndüm ve işlerin akışına geri dönmeye çalışıyorum. Bu alanda paylaşılan deneyimlerin akademik ve profesyonel deneyimlerime dayandığını vurgulamak istiyorum. Bu nedenle, burada anlatılanların gerçekliğin yalnızca bir kısmını temsil edebileceğini ve belirli süreçler, prosedürler veya hizmetler için kesin bir formül olarak yorumlanmaması gerektiğini hatırlamak önemlidir.

Kariyerimin bu yeni aşaması için şu anda çok heyecanlıyım. Çok şey öğrendim ve bu yolculuğun bir kısmını toplulukla paylaşmak istiyorum. Burada sunulan bilgilerin okuyucular için büyük değer taşımasını umuyorum.

Önce İnsanlar - Yumuşak Becerilerin Önemi

Birkaç yıl önce ilk seçim sürecime katıldığımda, neredeyse sıkıcı olan aşamaları net bir şekilde hatırlıyorum: İK ile görüşme, pratik test, teknik liderle görüşme ve son olarak yöneticiyle görüşme. Bir geliştirici olarak kariyerim boyunca, farklı modellerle birçok görüşmeye katıldım. O zamanlar, İK çalışanlarıyla görüşme yapmaktan her zaman rahatsız olurdum. Nedenini tam olarak anlayamamıştım, "Teknik testte isteneni yapabiliyorsam, pozisyon için zaten yeterli yeterliliği gösteriyorumdur." diye düşünüyordum.

Teknik geliştirme lideri rolümü üstlendiğimde, sorumluluklarımdan biri İK ile işbirliği yapmaktı (evet, seçim sürecine katılma sebebimi anlamadığım aynı kişiler) teknik bir test hazırlamak ve backend alanından başlayan iki aday için mülakat formatını tanımlamaktı. Backend alanında yeni başlayan bir geliştiricinin ne sunması gerektiğini ve testte neyin farklılaştırıcı olarak kabul edileceğini zaten bildiğimi düşünüyordum. Ancak beklemediğim şey, kodun önemine rağmen proje tesliminin ötesinde başka taleplerin ortaya çıkmasıydı: Adaylar iletişim açısından nasıl değerlendirilecek? Pozisyona olan ilgileri ne? Ve sundukları bağlam önerilen pozisyon için uygunluklarını nasıl etkileyebilir? Bu ve diğer sorular, her iki adayın sunduğu kod kadar önemli çıktı; bu, bir geliştirici olarak ilk yıllarımda daha önce düşünmediğim bir şeydi.

Son kararı vermek için toplantı masasına oturduğumu ve her adayın teknik becerileri hakkında ne kadar az konuşulduğunu fark ettiğimde biraz şaşırdığımı hatırlıyorum. Bunun bir kısmı, giriş seviyesi adaylar olmalarıydı, bu yüzden teknik becerilerinin bu kadar gelişmiş olmasının beklenmesi gerekiyordu ve bu, tartışmanın ana odağı değildi.

Ancak, daha ileri seviyedeki boş pozisyonlar için bile, özellikle üst düzey pozisyonlar için, iletişim, dokümantasyon, uyum sağlama, proaktiflik ve sıklıkla bahsedilen diğer beceriler gibi becerileri göz önünde bulundurmak çok önemlidir. Bu yumuşak beceriler temeldir ve teknik becerilere ek olarak rolde başarı için belirleyici olabilir. Aslında, bu benim bir sonraki noktam.

Junior ile Senior arasındaki çizgi (Hayır, orta seviye değil).

Deneyim seviyeleriyle ilgili terimlerin anlamı ve sınıflandırılması hakkında çok fazla tartışma olduğunu biliyorum, örneğin "kıdemli". Bazıları "kıdemli"nin deneyim yıllarıyla tanımlandığını" söylerken, diğerleri "bazı şirketlerde bir yıl sonra kıdemli deneyim kazanıyorsunuz" iddiasında bulunuyor. Ayrıca "junior ve senior arasında net bir ayrım olmadığını" veya "kıdemlilerin yalnızca kod incelemeleri yaptığını ve PR'leri onayladığını" söyleyenler de var. Bu ifadelerden bazıları komik, bazılarında ise bir parça doğruluk payı var. Gerçek şu ki "kıdemli" kavramı oldukça çeşitlidir ve evrensel bir standart tanımlamak bana düşmez, ancak bu sınıflandırmayı daha bireysel bir şekilde anlamak için biraz rehberlik sunabilirim.

Kıdemli olmak yalnızca teknik bilgiyle ilgili değildir, ancak bu şüphesiz çok önemlidir. Gerçek bir kıdemli veya en azından iyi bir kıdemli, hem kod hem de sistem mimarisi açısından karmaşık sorunları çözebilen kişidir. Kod kalitesini korumak, iyi geliştirme uygulamalarını takip etmek ve proje yönetimi bilgisine sahip olmak hayati öneme sahiptir.

Temel fark, kıdemli birinin tüm bunları özerk bir şekilde yürütebilmesi ve daha da önemlisi, mümkün olan en iyi projeyi sunmak için farklı düzeylerden ve sektörlerden ekiplerle iş birliği yapabilmesidir. Dahası, gerçek bir kıdemli (veya en azından en iyileri) yalnızca ekibi yönetmekle ve yönlendirmekle kalmaz, aynı zamanda diğer geliştiricileri yeni pozisyonlar ve sorumluluklar almaya hazırlar ve geliştirir.

Bir projeye liderlik etme konusunda ilk deneyimim

İlk projemi üstlendiğimde, patronum daha önce başka bir projeye liderlik etmediğimi biliyordu. Sadece geliştirmeye katıldım ve yönetimle iletişim açısından geliştirmeyi kolaylaştıracak bazı şeyler üzerinde çalıştım. Bana sorduğu ilk soru şuydu: "Projeyi tamamlamak için kaç kişi ve ne tür kişiler yeterli olacak?" Cevabı hemen bilmiyordum, çok karmaşık bir soruydu. Proje sadece taslak halinde olduğu için, yığın, her görevi tamamlamanın ne kadar zaman alacağı ve yukarıdaki kişilerin ilgisini çeken diğer ölçütler hakkında hiçbir fikrimiz yoktu. Ertesi gün birkaç proje yönetim metodolojisi üzerinde teslim edebilmek için kapsamlı bir çalışma yaptım: Pert, Planning Poker En uygun olanı iş birliği içinde seçtik ve meydan okuma başladı. Ekibin her üyesi için en iyi geliştirme platformu nedir, kullanılacak en iyi yığın nedir, sistem mimarisinin nasıl çalışacağı, piyasadaki diğer çözümleri incelemek, her geliştiricinin seviyesini izlemek, yönetimle toplantılar, toplantılar ve daha fazla toplantı .

En az farkına vardığımda, koddan giderek uzaklaşıyordum. Rolüm, projenin çalışabilmesi veya en azından geliştiricilerin başlaması için sağlam bir temel sağlayabilmesi için iyileştirmeler önermek ve bazı kritik hataları düzeltmek oldu. İşin geri kalanı geliştiricilerle iletişim kurmak, görevleri bölmek, ölçümleri izlemek ve temelde bir gözüm Asana'da (proje teslim süresini tahmin etmek için) ve diğer gözüm Meet'te olmak üzere mikrofonumun açık olmadığından ve istenmeyen hiçbir şeyin "kazara" geçmediğinden emin olmaktı.

Sonuç ve geçmişe bir bakış - ustaya sevgiyle

Kariyerime bir geliştirme stajyeri olarak başladım ve ilginç bir şekilde -ve bunu benim açımdan biraz çelişkili bulabilirsiniz- beni junior, tam veya kıdemli geliştirici olarak sınıflandıracak somut bir deneyimim (en azından istihdam kaydımda resmi olarak kayıtlı olmayan) yoktu. Kazandığım deneyimin çoğu üniversitedeki kişisel projelerden ve araştırmalardan geldi. Becerilerimin o ilk günlerden beri geliştiğini fark edene kadar kademeli bir süreçti.

Ama evet, kariyerim boyunca farklı seviyelerde yoğun bir şekilde geliştirici olarak çalıştım ve farklı türden kıdemli profesyonellerle tanışma fırsatım oldu:

1. Çok yetenekli ve etkili ama iletişimsiz, yaklaşımını açıklamadan sorunları çözen kıdemli.
2. Üst sınıf öğrencisi iletişim ve öğretme konusunda mükemmeldir, ancak sıklıkla acil görevlerle boğuşur ve öğretmeye zaman bulamaz.
3. Teknolojiyi aşırı mühendislik ve merkezileştirme konusunda hevesli olan, ancak son teslim tarihlerine uyan ve söz verdiği şeyleri teslim eden kıdemli kişi.

En önemlisi, haklı kusurlarına rağmen (mümkün olsa da talepleri dengelemek çok zordur), bu profesyonellerin hepsinin öğretecek değerli bir şeyleri vardı. Bu deneyimler kariyerimi şekillendirmeme yardımcı oldu ve bana sistem geliştirmede neyin işe yarayıp neyin yaramadığı konusunda net bir görüş sağladı.