Yazılım Sektöründe Kariyer Basamakları

Merhabalar,

Enginnering manager pozisyonu ile ilgili yazdığım ikinci yazı ile karşınızdayım. Genel olarak duygu ve düşüncelerimi paylaştığım ilk yazıya şuradan ulaşabilirsiniz.

Bu yazıda engineering manager nedir, kariyerimizde hangi aşamada karşımıza çıkar konusu hakkında yazacağım.

Bir önceki yazıda da belirttiğim gibi kariyerimizde belirli bir süre ilerledikten sonra bir anda kendimizi birkaç insandan veya birkaç projeden sorumlu halde bulabiliriz. Peki ama bu gerçekten bir anda mı oluyor? Buraya gelene kadar hangi aşamalardan geçiyoruz? Diyelim ki junior developer olarak başladık ama 2 yıl çalıştıktan sonra kendimize mid-level diyebilir miyiz? Eğer diyebilirsek 3 yıllık tecrübesiyle senior olanlar gökten mi iniyor nasıl oluyor bu iş?

En son söyleyeceğimi en başta söyleyeyim de ortadaki gerginlik kalksın. Bütün title’lar bizim uydurduğumuz şeyler. Eğer size şirketiniz senior developer diyorsa pekala siz de kendinizi öyle tanıtabilirsiniz. Şirketinizi size senior demekten alıkoyan hiçbir şey yok, diyebilirler. Sizin de giriş kartınızda senior yazıyor kocaman, siz de haklısınız. Başka şirkete mülakata gittiğinizde bizce senior değilsin derlerse onlar da haklı. Bu işin bir sınavı yok ki ispatlayalım değil mi? Mesela benim ilk çalıştığım şirkette (bkz. Tart New Media / Startup Kitchen) Star Wars ünvanları kullanırdık. Şirkete Youngling (bir nevi stajer) olarak girdim. Sonrasında da Padawan (Jr. Dev) makamına eriştim. Jedi olmaktı hayalim ama olamadım. Dolayısıyla birisinin çıkıp 4 yıllık tecrübeyle Jedi olamazsın demesiyle senior olamazsın demesi bence aynı şey. Tekrarlayalım: bunların hepsi uydurma şeyler. Birisi çıkıp bunun tanımını yapıp kurallarını koyana kadar kanunlar çerçevesinde herkes kendine istediği şeyi diyebilir.

Ama şimdi hayattaki her tanım bizim uydurduğumuz şeyler zaten. Böyle diyince kendimi bir anda hayatı sorgularken buldum bak yazıya başlarken hiç böyle planlamamıştım. Fazla dağıtmadan konuya dönüyorum hemen. Her şey uydurma tabii ki ama ben size junior, senior dediğimde kafanızda bir şeyler canlanıyordur eminim. Benim kafamda ne canlanıyor kısaca aktarayım. Kabaca yazılım kariyeri şöyle bir şey:

Junior Developer 🐣

Kariyerimize genelde buradan başlarız. Belli başlı teknik konulara aşinayımdır. Bana bir görev verilirken problem tanımının yanısıra genelde çözümünün de beraber söylenmesi gerekir. Çok sık yönlendirmeye ihtiyaç duyarım. Bu sebeple çevremdekilere bolca soru sormam dünyanın en doğal şeyi olmasına rağmen milletin vaktini mi alıyorum diye stres yaptığım için yeterince soru sormaya çekinirim 😄 Daha tecrübeli biriyle beraber çalışırsam uçtan uca geliştirmelere de destek sağlarım. Uğraştığım her iş benim için öğrenilmesi gereken yeni bir alan olduğu için sık sık ben bu meslekte tutunamayacak mıyım, yol yakınken marangoz mu olsam acaba diye sorgularım.

Mid-level Developer 🐥

Artık bazı konularda hiç destek almadan bana verilen görevleri tamamlar hale gelmişimdir. Birkaç teknik konuda artık daha derinlemesine bilgi sahibiyimdir. Kendi takımımı ilgilendiren projeleri ufak yardımlarla da olsa baştan sona yürütecek teknik yeterliliğe ulaşmışımdır. Daha tecrübeli takım arkadaşlarımla beraber çalışarak birkaç farklı takımı etkileyecek projelerde hatırı sayılır derecede katkı sağlarım. Özetle artık daha büyük problemler ile uğraşırım. Hatta problem çalıştığım yerden gelirse direkt olarak kodlamaya hazır çözümler sunabilirim. Sunduğum çözüm çok beğenilirse ya ben bu işi artık beceriyorum galiba diye özgüvenim tavan yapar ve yürüyüşüm falan değişir. Fakat problem bazen de çalışmadığım yerden gelir. 3 gün uğraşıp çözemediğim sorunu senior takım arkadaşım 40 dakikada çözünce yine marangoz mu olsam acaba diye düşüncelere dalarım.

Senior Developer 🐔

Artık günlük hayatta karşılaştığım problemlerin çoğu daha önce gördüğüm problemler haline gelmiştir. Yazılım mimarisi, design patterns, development methodologies gibi kavramları artık neredeyse içselleştirmişimdir. Dolayısıyla teknik sorunlara durumun gerektirdiği çözümler bulmakta zorlanmam. Yeteneklerim sadece teknik alanda da sınırlı değildir. Birkaç takımı etkileyecek projeleri baştan sona götürebilirim. Problem tanımı yapıldıktan sonra yazılan RFC’den (bkz RFC nedir?), projenin canlıya çıkıp son kullanıcıya ulaşana kadar olan döngüyü tamamlayabilirim. Bunu yaparken de projenin maliyetini hesaplamak, takımın adım adım geliştirebileceği parçalara bölmek, iş bölümü yapmak, diğer takımları yönlendirmek, gerekirse PM ile pazarlık yapmak zorlanmadan yaptığım şeyler haline gelmiştir.

Yavaş yavaş sektörde yıl aldıkça çoğu teknik problemin aslında teknik değil de insan problemi olduğunu farkederim. Hiçbir sorunun tek bir genelgeçer çözümü olmadığını farkederim. Her soruya uzaklara bakarak “it depends” diye yanıt veririm. Yeni bir şirkete geçerken genelde heyecanlanmam çünkü günün sonunda hemen hemen aynı işi yapıyoruzdur. Hayattan ufak da olsa bir bezmişlik vardır. Ya aslında 2-3 tane side project yapıp oradan para kazanıp köşeyi dönmek lazım abi bizim Murat var bak hayatı yaşıyo diye düşünürüm ama yapmam. Ve evet tahmin ettiğiniz gibi günün sonunda yine marangoz mu olsam acaba ya düşüncesi gelir akıllara…

Sonra? 🦕

Şimdi buraya kadar çok iyi geldik bence. Kariyer basamaklarını çıktık birer birer. Marangoz falan da olmadık, sektörde ilerliyoruz, Twitter’da linçlere katılıyoruz, birkaç ayda bir setup’larımızı paylaşıyoruz. Kelimenin tam anlamıyla yazılımcıyız yani. Genelde bu civarlarda insanın aklına bir soru takılıyor. Ee şimdi n’olcak? Senior bile olduk önümüzdeki 25 sene böyle mi geçecek?

Aslında yukarıda senior tanımını yaparken hile yaptım. Araya çaktırmadan liderlik ile ilgili sorumluluklar da ekledim. Sektörde benim gördüğüm kadarıyla bu kısım şirketten şirkete değişiyor. Bazı şirketlerde senior pozisyonundan beklenti çoğunlukla teknik yetkinlikle alakalı. Eğer yukarıda belirttiğim gibi sorumluluklar yüklenmeye başladıysa bu pozisyona Tech Lead deniyor. Bazı şirketlerde ise böyle bir pozisyon yok. Bu ufak yöneticilik ve liderlik işleri zaten senior pozisyonundan beklenen sorumluluklar içinde değerlendiriliyor.

Bazı şirketler sağolsun size zaten tek bir kariyer rotası sundukları için çok düşünmenize gerek kalmıyor. Birden kendinizi takımdan sorumlu buluveriyorsunuz. Genelde takımın en eskisi veya teknik anlamda en yetkin insanını hop diye takım lideri yapıveriyorlar. Teknik anlamda gerçekten çok, çok iyi bir sürü insanın ya aslında yönetici olmak istemedikleri için ya da bu konuda çok eğitimsiz ve/veya hazırlıksız oldukları için gerçekten kötü birer yönetici olduklarına çok kez şahit oldum. Kazananı olmayan bir durum.

Ben burada teknik ve yöneticilik kariyer basamaklarını ayıran şirketlere odaklanmak istiyorum. Genelde karşımıza şu şekilde bir ayrım çıkıyor:

Peki bu akışa göre yöneticilik sorumlulukları olan bir senior developer ile, yani tech lead ile engineering manager arasındaki fark nedir? Yine bu sorunun da cevabı şirkete göre değişiyor. Genel olarak tech lead dediğimiz pozisyonun zamanının çoğu teknik problemler çözerek geçerken, engineering manager pozisyonu “insan” problemlerine odaklanıyor. Futboldan da hiç anlamam ama sanırım takım kaptanı ile teknik direktör arasındaki fark gibi ama yazılımda fark bu kadar bariz değil. Bu çok kötü örnekten sonra biraz gerçek hayattan birkaç örnekle netleştirmeye çalışayım.

Tech lead genelde bir projeyi (bazı durumlarda birden fazla da olabilir) teknik anlamda

• en iyi çözümle
• en kısa sürede
• en az teknik borçla
• en verimli çalışacak şekilde
• …

teslim etmek için ne yapmak lazım sorularına odaklanır. Bu listeyi aşağıya kadar uzatabiliriz ama ana nokta, bunların hepsi teknik odaklı sorunlar. Peki tech lead bunları yaparken engineering manager ne yapıyor? Burada da benim kuzey yıldızım “delivery”. Yani ben bu pozisyondayken takımımın iş teslim etmesinden sorumluyum. Bunları yaparken

• takımdaki insan sayısı, işe alım, takım bütçesi
• kariyer planlamaları, terfiler, mentorluk, birebire görüşmeler
• takımımın diğer takımlarla olan iletişimi ve bu noktalarda çıkacak olası problemler
• takımdaki insanların mutluluğunu, üretkenliğini, verimliliğini gösteren metrikler
• teslim ettiğimiz işler şirketin vizyonuyla, misyonuyla, hedefleriyle uyumu
• …

konularına odaklanıyorum. Yine bu listeyi de uzattıkça uzatabiliriz fakat ana noktayı belli ettik galiba. Bulunduğum takımın en iyi işi çıkarabilmesi için gerekli planlamaları yapıp yoldaki engelleri temizliyorum.

Sonradan ekleme: bu yazıyı birkaç arkadaşıma okuttum ve bir popüler soru aldım: “abi ben anlamadım kod yazıyor musun yazmıyor musun?” 😄 Evet yazıyorum ama çok az. Kod yazmamın amacı işin bir ucundan da ben tutayım kesinlikle değil. Kod yazdığım zaman takımdaki insanları rahatsız eden şeyleri birinci elden tecrübe edebiliyorum. Bu en büyük amacım. Kendi bilgisayarında testleri çalıştırmak çok zorsa bunu takımdan biri şikayet etmeden görebilmemin tek yolu bu. Teknik anlamda da takımdan kopmamak için bol bol code review yapıyorum. Sadece kodun kendisini değil, review edenleri de review ediyorum. Kim neye dikkat etmiş, ne kadar detaylı code review yapmış gibi şeyleri görmeme de yardımcı oluyor. Her yazılan teknik dokümanı kesinlikle okuyorum. Takımın uğraştığı (ve önümüzdeki 3 ay uğraşacağı) projelerin hepsini zaten biliyorum fakat takım bu sorunları tam olarak nasıl çözüyor bilmem çok çok önemli. Sistemin sağlığı hakkında bilgilerimi taze tutmak için de on-call rotation’da yer alıyorum. Yani evet, kod yazıyorum ama önceliğim o değil.

Bu seride kendim yeni yeni öğrendiğim şeyleri yazmaya devam edeceğim. Herhangi bir yorumun varsa lütfen bana iletmekten çekinme.

Görüşmek üzere 🙌

📝 Eklemeler:

• Kariyer basamaklarını senior seviyesinde bıraktım çünkü genelde engineering manager pozisyonu buradan başlıyor. Staff, Principal Engineer, Senior Principal, Distinguished Engineer ve daha ilerisi pozisyonları başka bir yazıda tartışırız. Ben de tam ne yapıyorlar bilmediğimden değil yani yazı uzamasın diye. Yoksa sabaha kadar yazarım.
• Kariyer basamakları grafiğini buradan aldım: https://www.levels.fyi/blog/what-are-career-levels-ladders.html
• Bir sürü terimi günlük hayatta Ingilizce kullandığım haliyle yazdım. Biliyorum hepsinin bir Türkçe karşılığı var ama bu yazıyı kendim okumak istesem böyle okumak isterdim heralde. O yüzden böylece bırakıyorum.