İletişim, Bir Sonraki Mühendislik Seviyenizin Kapısıdır

Doğru ve güvenilir kod çıkaran bir mühendis, birkaç değerlendirme dönemi boyunca aynı seviyede kalabilir ve her seferinde aynı geri bildirimi duyabilir: teknik iş güçlü, etki alanı dar. Bu geri bildirimin arkasındaki kısıt yapısaldır. Senior seviyesinden yukarısı, tek kişinin tek başına yürütemeyeceği bir kapsamla puanlanır; o büyüklükteki kapsama ise ancak başka insanların kararları üzerinden ulaşılır. Herkese açık kariyer basamakları bunu açıkça söyler. Dropbox’ın çerçevesi her seviyeyi Kültür sütunu altındaki bir İletişim satırı ve etkinizin ne kadar uzağa ulaştığını ölçen Collaborative Reach (iş birliği erişimi) boyutu üzerinden puanlar; dört sütunlu modeli yaygınlaştıran Rent the Runway basamağı ise “İletişim ve Liderlik”i dört sütundan biri yapmıştır. Bu yüzden iletişimi, artefaktları, incelemesi ve iterasyonu olan bir mühendislik becerisi gibi ele alın. İşe yazılı, asenkron artefaktla başlayın: dokunduğunuz belirsiz her karar için bir tasarım dokümanı ya da karar notu, sonucu ilk paragrafta olacak şekilde. Beceri yedi somut yüzeye ayrılır: tasarım dokümanları, sonuçla açılan güncellemeler, mühendis olmayanlar için ödünleşim çerçevesi, inceleme yorumları, yapılandırılmış itiraz, özgül sorular ve koordinasyon işinin bıraktığı kayıt. Her birinin tanınabilir bir önce/sonra hâli vardır; hangisinde önce pratik yapılacağı ise işinizin nerede görünmez kaldığına bağlıdır.

Seviye Yükseldikçe Kaldıracın Kaydığı Yer#

Tipik bir basamağın her seviyesi, çıktınızın neyden oluştuğunu değiştirir. Yazdığınız kod, senior civarında bir yerde ölçü birimi olmaktan çıkar; ondan sonra birim önce ekibin çıkardığı kod, sonra etkilediğiniz kararlar, en sonunda da başkalarının sizin çerçevenizi kullanarak belirlediği yön olur.

Basamaklar bu kaymayı kendi cümleleriyle anlatır. Dropbox’ın IC4 satırı, “mesajımı netlik, kısalık ve odakla, dinleyiciye göre uyarlayıp uygun ayrıntı düzeyinde sunan” ve “farklı dinleyici kitlelerinden paydaşları etkileyen” bir mühendis bekler. Staff seviyesi olan IC5’te dile, “farklı dinleyici kitlelerinden paydaşların onayını alma ve onları etkileme yaklaşımını ince ayarlama” beklentisi eklenir. GitLab’ın açık matrisi iletişim yetkinliklerini Senior ve Staff için ayrı ayrı listeler. Gergely Orosz aynı noktayı yazma tarafından kurar: hızlı büyüyen startup’lardaki ve büyük teknoloji şirketlerindeki mühendisler çoğu zaman günde koddan daha fazla kelime yazar ve belli bir seviyenin üzerinde zayıf yazı, ilerlemeyi frenleyebilir. Her seviyede kod yazmaya devam edersiniz; değişen şey, o kodun hangi kararların içinde yer aldığıdır.

Bu satırların her biri başka birinin kararındaki bir değişimi tarif ettiğinden, hiçbiri yalnızca daha iyi kod yazarak karşılanamaz. Kariyer seviyeleri yazısı bir basamağın nasıl bir sohbet rehberi olarak okunacağını anlatır. Basamağın işaret ettiği beceri ise bir dizi yüzeyden oluşur; en kalıcı kaydı bırakan yüzeyle başlamak gerekir.

Belirsiz Her Karar İçin Bir Tasarım Dokümanı#

Malte Ubl’un Google’daki tasarım dokümanlarını anlatan yazısı, işe buradan başlamanın gerekçesini verir. Doküman, tasarım sorunlarının “değişiklik yapmanın hâlâ ucuz olduğu” anda yakalandığı yerdir ve “senior mühendislerin bilgisini organizasyona ölçeklemenin” mekanizmasıdır. Senior bir mühendis her değişikliği inceleyemez ama dokümanı inceleyebilir. İki özellik de tam olarak basamağın ölçtüğü şeydir. Doküman siz orada olmadan ölçeklenir ve terfi dosyasının işaret edebileceği bir artefakt bırakır.

Çoğu ilk taslak, dokümanın kendisini tarif ederek açılır. Okunan taslakla göz gezdirilip geçilen taslak arasındaki fark, genellikle ilk paragraftaki bilgi sırasıdır.

Önce:

Bu doküman, bildirim servisinin polling modelinden mesaj kuyruğu kullanan event-driven bir modele geçişini anlatmaktadır. 2. bölümde mevcut mimari, 3. bölümde önerilen mimari, 4. bölümde ise geçiş planı yer alır.

Sonra:

Bildirim teslimatını event-driven modele taşımalıyız. Polling, daha fazla düşüremediğimiz bir teslimat gecikmesi yaratıyor ve olay sayısından bağımsız, abone sayısıyla orantılı büyüyen bir yük ekliyor. Alternatif olan poll aralığını ayarlamak, iyileşmenin kabaca yarısını sağlıyor ve orada duruyor. Platform ve mobil ekiplerinden beklenen karar: at-least-once teslimatı kabul edip etmeyeceğimiz; kabul edersek tekilleştirme istemci tarafına geçer.

İkinci sürüm aynı olguları taşır. Değişen şey bilgi sırasıdır: öneri, gerekçe, elenen alternatif ve istenen somut karar, okuyucu okumaya devam edip etmeyeceğine karar vermeden önce gelir. Ubl’un önerdiği bölümler (bağlam ve kapsam, hedefler ve hedef olmayanlar, ödünleşimlere ağırlık veren tasarım, değerlendirilen alternatifler, güvenlik ve gözlemlenebilirlik gibi kesişen konular) türetmeyi isteyen okuyucular için sonrasında gelir. Tam bir RFC’nin mekaniğini RFC yazma rehberi ile teknik RFC anatomisi zaten anlatıyor.

Ödünleşim zamandır. Ubl, dokümanın çözüm belirsizken, senior görüşü değerliyken ya da tartışmalı bir tasarımda uzlaşı gerekirken yazılmaya değdiğini açıkça söyler. Apaçık çözümler ve atılacak prototipler ise doküman hak etmez. Tek sayfalık bir not çoğu kararı karşılar; uzun biçim, geri almanın pahalı olduğu kararlar içindir. Her şey için doküman yazmak amaçlanan sinyalin tersini üretir, çünkü okuyucular dokümanlarınızı atlamayı öğrenir.

Pratik bir alıştırma: bir hafta boyunca, bir iş arkadaşınızın makul biçimde farklı verebileceği her seçimde yukarıdaki dört cümlelik özeti yazın ve etkilenen ekiplerin okuduğu yere bırakın. Çoğu için tam doküman gerekmeyecektir. Aktarılan şey kararı, gerekçeyi ve isteği söyleme alışkanlığıdır. Haftanın sonunda elinizde, hangi kararların gerçekten doküman hak ettiğini gösteren küçük bir liste de olur.

Dört Satırlık Durum Güncellemesi#

Will Larson’ın yöneticilere sunum rehberi, SCQA (durum, karmaşıklık, soru, yanıt) ile açmayı, uzun dokümanlar içinse Barbara Minto’nun piramit ilkesini önerir. Larson’ın Minto’dan aktardığı cümle şudur: “fikirlerinizi sunma sırasını kontrol etmek, net yazının gerektirdiği en önemli tek eylemdir”. Durum güncellemesi bu sırayı çalışmanın en küçük yeridir. Okuyucunun ihtiyacı, sırasıyla durum, risk, plan ve istektir; üstelik herhangi bir satırdan sonra okumayı bırakabilmelidir.

Önce:

Ödeme retry işi üzerinde çalışıyorum. Dün sandbox’ta biraz sorun yaşadım. Backlog’dan iki bug daha aldım. Yarın devam edeceğim.

Sonra:

Ödeme retry: perşembeye yetişiyor. Risk: sağlayıcının sandbox’ı dün günün büyük kısmında kapalıydı, bu yüzden hata yolu testleri gerçek hata kodlarına karşı henüz çalışmadı. Çarşamba günü sandbox hâlâ kapalıysa feature flag arkasında çıkıp staging’de doğrulayacağım. Flag’in kapalı olmasını istemediğiniz sürece sizden bir karar gerekmiyor.

İlk sürüm etkinlik listeler; bir yönetici buradan endişelenip endişelenmemesi gerektiğini çıkaramaz. İkincisi durumu, riski, planı ve karar gerekmediğini açıkça verir. Larson’ın yönetici sunumları için saydığı anti-pattern’ler bu ölçekte de geçerlidir: önerilen bir yanıt olmadan soru getirmek, kendiliğinden çözülür umuduyla bir sorunu saklamak ve toplantı sırasında geri bildirimle tartışmak.

Sonuçla açılan yazının kolayca küçümsenen bir bedeli vardır. Öneriyi ilk satırda söylemek, argümanın tamamı kurulmadan itiraza davetiye çıkarır ve kaçamak yazmaktan daha savunmasız hissettirir. Pratikte bu savunmasızlık işin özüdür, çünkü erken gelen itiraz ucuz, inşa bittikten sonra gelen itiraz pahalıdır.

Tek Karar, Üç Farklı Dil#

Basamakların “doğru ayrıntı düzeyi” diye tarif ettiği hamle, teknik bir seçimi dinleyicinin sahip olduğu boyuta çevirmektir. Aynı veritabanı kararı üç farklı ilk cümleye ihtiyaç duyar.

Bir mühendis için ilişkisel veritabanı ile doküman deposu arasındaki seçim tutarlılık modeli, şemanın destekleyeceği sorgu desenleri ve operasyon yükünü kimin taşıyacağı ile ilgilidir. Bir ürün yöneticisi için aynı seçim, hangi özelliklerin ileride zorlaşacağıyla ilgilidir: varlıklar arası raporlama birinde ucuz, diğerinde pahalıdır; kiracı bazlı esnek alanlar içinse durum tam tersidir. Finans paydaşı için tek satır yeter: ilişkisel seçeneğin faturası veri boyutuyla, yönetilen doküman deposununki ise istek hacmiyle büyür. Seçim, ürünün bu ikisinden hangisini daha hızlı büyüteceğine bağlıdır. Üç cümlenin hiçbiri diğerinden daha az doğru değildir; her biri yalnızca dinleyicinin karar verebileceği boyutu öne alır.

Desen şudur: öneri, dinleyicinin boyutunda tek cümlelik gerekçe ve talep üzerine derinlik. Çoğu paydaş kararı ve kendi sahip olduğu riski ister; türetmeyi uzun uzun anlatmak, dinleyici karar verecek bir şey bulamadığı için kararı varsayılan olarak mühendisliğe geri iter.

Kodu Konu Alan İnceleme Yorumları#

Kod incelemesi, mühendislerin en sık ve en dikkatsiz iletişim kurduğu yüzeydir. Google’ın mühendislik pratikleri rehberi kanonik çifti verir.

Kötü: “Concurrency’nin belli ki hiçbir faydası yokken burada neden thread kullandın?”

İyi: “Buradaki concurrency modeli, görebildiğim kadarıyla gerçek bir performans kazancı sağlamadan sisteme karmaşıklık ekliyor. Performans kazancı olmadığına göre bu kodun birden çok thread yerine tek thread’li olması daha iyi.”

Çiftin arkasındaki kural, geliştiriciye asla değinmeden koda yorum yapmak ve nedenini açıklamaktır. Aynı biçimde, sıradan bir pull request’ten ikinci bir örnek:

Önce: “Bu neden ham SQL string’i?”

Sonra: “Bu sorgu SQL’i string birleştirmeyle oluşturuyor; modülün geri kalanının kullandığı parametre bağlamayı atlıyor. Query builder’a geçirmek injection korumasını repo genelinde tutarlı kılar.”

Yeniden yazılmış yorum, yanıt beklemeden uygulanabilir; içinde bir gerekçe olduğu için yazar katılmıyorsa hangi varsayıma itiraz edeceğini de bilir. Orijinali ise yazarın incelemecinin ne istediğini tahmin etmesini ve neyin yanlış olduğunu bilmeden bir seçimi savunmasını gerektirir. Rehber ayrıca incelemede iyi yapılmış işi adıyla anmayı önerir, çünkü iyi bir şeyi çoktan teslim etmiş bir thread’de değişiklik talebi farklı karşılanır. Google’ın yazarlar için hazırladığı eşlik sayfası öteki tarafı anlatır: eleştirel yorumları kod hakkında ifadeler olarak okumak ve savunmaya geçmeden önce açıklama istemek. Ekip düzeyindeki ele alış kod inceleme kültürü yazısında; bireysel beceri ise yukarıdaki iki yeniden yazımdır.

İtiraz, Koşul, Taahhüt#

Çoğu ekipte itirazın iki ayarı vardır, sessizlik ya da tırmandırma; ikisi de senior izlenimi vermez. Amazon’un liderlik ilkesi alternatif biçimi herkese açık biçimde söyler: liderler “katılmadıkları kararlara, rahatsız edici ya da yorucu olsa bile saygıyla itiraz etmekle yükümlüdür” ve “karar belirlendikten sonra ona tamamen bağlanırlar”.

Pratik dizi dört hamledir: ortak hedefi söyleyin; gördüğünüz somut riski kişide değil, öneride adlandırın; fikrinizi değiştirecek koşulu verin; karar öteki yöne giderse ne yapacağınızı belirtin. Bir tasarım incelemesi thread’inde şöyle görünür:

İkimiz de geçişin yoğun sezondan önce bitmesini istiyoruz. Benim endişem dual-write aşamasında: iki depo birkaç dakikadan uzun süre birbirinden ayrışırsa uzlaştırma canlı trafik üzerinde çalışır. Cutover’dan önce bir production snapshot’ı üzerinde uzlaştırmanın çalıştığını görebilirsem içim rahat. Ekip bunu yapmadan ilerlemeye karar verirse uzlaştırma runbook’unu ben üstlenirim; böylece her iki durumda da hazır oluruz.

Larson’ın ön hizalama tavsiyesi de buraya aittir. Taslağı erken dolaştırın, muhtemel itirazcılara neyin değişmesi gerektiğini sorun ve itirazları toplantıdan önce toplayın. Toplantı böylece ilk okumaya ev sahipliği yapmak yerine bir karar kaydeder ve yukarıdaki itiraz, veriyle yanıtlanabileceği bir thread’de dile getirilmiş olur.

Görünür Bir Sinyal Olarak Net Sorular#

Ortak bir kanalda net düşünmenin en ucuz görünür sinyali iyi kurulmuş bir sorudur. Julia Evans’ın iyi soru sorma rehberi, özgüllük argümanını küçük bir örnekle kurar: “SQL join’ler nasıl çalışır?” yerine “N ve M boyutunda iki tabloyu join’lemenin zaman karmaşıklığı nedir?” diye sorun. Mevcut anlayışınızı da önce söyleyin ki uzman sıfırdan başlamak yerine sizi düzeltebilsin. Aynı biçim yanıtlamak için de çalışır: soruyu anladığınız hâliyle yeniden ifade edin, yanıtı verin, sonra çekinceyi ekleyin. Bu, bir haftada yürüyen düşük riskli bir alıştırmadır ve kanaldaki herkes tarafından okunur.

Koordinasyon İşinin Bıraktığı Kayıt#

Tanya Reilly’nin “Being Glue” konuşması, bir ekibi ayakta tutan ama terfi süreçlerinin çoğu zaman saymadığı koordinasyon, mentorluk, not tutma ve önünü açma işine ad verir. Tavsiyesi kredi almak yerine iz bırakmak üzerinedir: tasarım önerileri, karar kayıtları ve toplantı notları gibi artefaktlar üretin ki yargı size atfedilebilsin. İş yine de sayılmıyorsa bir kısmından bilinçli olarak geri çekilin ve bunu söyleyin.

Kaydı doğru kılan iki alışkanlık vardır. İlki kendi güncellemelerinizdeki sahiplik dili: cümle doğruysa refleksle “yardım ettim” demek yerine “tasarım incelemesini yönettim”. İkincisi, koordine ettiğiniz bir toplantının ardından ilgili ekiplerin okuduğu yere bırakılan yazılı karar kaydı; böylece sonuç, kaydırılıp kaybolan bir thread’e değil bir dokümana atfedilir. Altyapı olarak dokümantasyon yazısı ile ekip dokümantasyonu rehberi bu kayıtların nerede yaşayacağını anlatır.

Bunun bir karşı ağırlığı var. Charity Majors’ın mühendis/yönetici sarkacı, teknik güvenilirliğin uygulamalı işe yakın kalmaktan geldiğini ve tamamen koordinasyona kaymanın, konuşarak geri kazanılamayacak bir güvenilirliğe mal olduğunu savunur. Larson ve Reilly ise etki işini staff rolünün çekirdeği olarak sunar; iki konum aynı anda geçerlidir. Staff yolu teknik yargının hâlâ güncel olduğunu varsayar; iletişim işi, o yargının tek ekibin ötesine ulaşma biçimidir. İnşa etmeyi bırakan bir mühendis, yazının taşıması gereken şeyin kendisini kaybeder.

Önce Hangi Yüzeyde Pratik Yapmalı#

Varsayılan yazılı dokümandır, ama doğru ilk yüzey sinyalin nerede kaybolduğuna bağlıdır. Aşağıdaki ağaç geri bildirimden başlar ve gözlemleyebildiğiniz şeye göre dallanır. Dallar birbirini dışlamaz; çoğu mühendis birkaç çeyrek içinde hepsinden geçer. Son yaprak, yani inceleme, mentorluk ve devretme yoluyla başkalarını desteklemek, kendi yüzeyleriniz görünür olduktan sonra işin gittiği yerdir: staff üstü basamak, sizin sayenizde başkalarının çıkardığı işi sayar.

Aynı dallar tablo hâlinde, fark edeceğiniz sinyal ve her önerinin arkasındaki kaynakla birlikte:

Durum	Fark edeceğiniz sinyal	Önce nereye yatırım yapmalı	Neden
İş ekibin dışında görünmüyor	Değerlendirme sohbetinde işaret edilecek artefakt yok	Tasarım dokümanı ya da karar notu	İncelenebilir kaydı oluşturur; Dropbox IC4’ün “paydaşlar bilgilendirilsin ve hizalansın diye bilgiyi proaktif paylaşma” beklentisiyle örtüşür
Dokümanlar var ama kimse okumuyor	Yorumlar yalnızca kendi ekibinizden geliyor	Sonuçla açılan özetler, daha kısa dokümanlar, hedefli dolaşım	Okumak bir maliyettir; SCQA onu düşürür
Okuyucu teknik değil	Sorular “bu bizim için ne demek” biçiminde geri geliyor	Paydaş boyutuna göre ödünleşim çerçevesi	Dropbox IC3’ten IC5’e uzanan “doğru ayrıntı düzeyi” dili
Kararlar toplantıda veriliyor	Dokümanlar onaylanıyor, sonra odada geçersiz kılınıyor	Toplantı öncesi ön hizalama	Larson: erken taslak gönderin, neyin değişmesi gerektiğini sorun
İnceleme thread’leri sürtünme üretiyor	Uzun yorum zincirleri, yavaş merge’ler	Koda yorum yapın, gerekçeyi verin	Google mühendislik pratikleri
Verilmiş bir yöne katılmıyorsunuz	Aynı tartışma tekrar tekrar açılıyor	Yapılandırılmış itiraz, ardından görünür taahhüt	Amazon’un “Have Backbone; Disagree and Commit” ilkesi
Çok koordinasyon yapıyor, kredi almıyorsunuz	Kendi güncellemelerinizde “yardım ettim” dili	Artefaktlar ve sahiplik dili	Reilly, “Being Glue”

Yazılı Varsayılanın Kaybettiği Durumlar#

Üç durum varsayılanı geçersiz kılar ve her birinin adlandırılmış bir alternatifi vardır.

İlki, toplantıda karar veren ve doküman okumayan bir organizasyondur. O ortamda iyi yazılmış bir RFC okuyucu bulamadan batar. Yatırım o zaman ön hizalama sohbetine gider: aynı içerik, toplantıdan önce paydaşlara tek tek anlatılır; doküman ise girdi olmak yerine sonradan tutulan kayıt olur. Karar yine yazıya geçer; yazı yalnızca kararın verilme biçimi olmaktan çıkar.

İkincisi, uzun biçimle kısalık arasındaki gerilimdir. Amazon’un 2017 hissedar mektubu altı sayfalık anlatı notlarını toplantılarının standart girdisi olarak tarif eder ve iyi notların “yazılıp yeniden yazıldığını, işi iyileştirmeleri istenen meslektaşlarla paylaşıldığını, birkaç gün kenara konup sonra taze bir zihinle yeniden düzenlendiğini” ve “bir iki günde yazılamayacağını” söyler. Larson ve Minto tam ters refleksi savunur: sıkıştırın, yanıtla açın, okuyucunun erken bırakmasına izin verin. İkisi de farklı dinleyiciler için haklıdır: sessizce okuyan bir karar forumu ile altı dakikası olan bir yönetici. Uzlaşı, uzunluğu kararın geri alınma maliyetine göre seçmek ve her durumda önce kısa sürümü yazmaktır; iyi bir uzun not da yukarıdan aşağıya okunabilir.

Üçüncüsü zaman ufkudur. Basamaklar, bir değerlendirme dönemi ya da daha uzun süre boyunca gösterilen davranışa göre terfi verir; bu yüzeylere yapılan yatırım bir sonraki sohbette görünmez. Bu beklentiyi baştan yöneticinizle kurun ve hangi basamak satırlarını hangi artefaktın karşılayacağı konusunda anlaşın ki ikiniz de aynı kanıtı arıyor olun. Bu anlaşma, bir sonraki değerlendirmede “daha geniş etki” cümlesinin yeniden ve tanımsız biçimde ortaya çıkmasını da önler.

Seviyeyi Yerinde Tutan Alışkanlıklar#

Bazı desenler, iletişim gibi görünürken bir mühendisi güvenilir biçimde aynı seviyede tutar. Her birinin çözümü yukarıdaki yüzeylerden birine geri döner.

• İletişimi daha çok konuşmakla eşitlemek. Daha fazla toplantı ve daha fazla sunum, artefakt eklemeden görünürlük ekler. Çözüm haftada bir yazılı artefakttır; her biri bir öncekinden daha kısa ve daha net.
• Dokümanı karardan sonra yazmak. Zaten inşa edilmiş bir şeyi gerekçelendirmek için yazılan doküman ilgi görmez, çünkü karar verilecek bir şey kalmamıştır. Yanıt hâlâ açıkken yazın; incelemenin ucuz olduğu tek an odur.
• Öneriyi üçüncü sayfaya gömmek. En üstte üç cümlelik bir özet, gövdeyi türetmeyi isteyen okuyuculara ayırmak bunu içerik kesmeden düzeltir.
• Etkinlik listeleyen durum güncellemeleri. “Geçiş üzerinde çalıştım” cümlesi okuyucuya endişelenip endişelenmemesi gerektiğine dair hiçbir şey söylemez. Durum, risk, plan, istek.
• Kişiye dönük soru biçiminde inceleme yorumları. “Neden … yaptın” neredeyse her zaman “Bu yaklaşım Y olmadan X ekliyor, dolayısıyla…” biçiminde yeniden yazılabilir ve yazar bunu uygulayabilir.
• İtirazı ikili görmek. Sessizlik de tırmandırma da yukarıdaki dört hamlelik dizinin başarısızlığıdır; orta yol, koşul eklenmiş itirazdır.
• Mühendis olmayanlara fazla açıklamak. Tek satırlık öneri ile dinleyicinin sahip olduğu risk, talep üzerine derinlikle birlikte bir karar getirir; tam türetme ise işi size geri devreder.
• Görünmeden koordine etmek. Yürüttüğünüz bir kararın tek izi bir sohbet thread’iyse basamak onu göremez.
• Basamağı kontrol listesi gibi okumak. Kariyer seviyeleri yazısı basamakların sohbet rehberi olduğunu savunur; istedikleri kanıt başka birinin kararındaki değişimdir ve işaretlenmiş kutuların sayısı bunun yerini tutmaz.

Saymaya Değer Sinyaller#

Bunların hiçbiri bir dashboard gerektirmez; her biri kendi kendinize tutabileceğiniz bir sayımdır ve hiçbiri yayımlanacak bir rakam değildir.

• Çeyrek başına yazdığınız tasarım dokümanı ya da karar notu sayısı ve kaçının ekibinizin dışından yorum aldığı.
• Bir öneriyi dolaşıma sokmaktan kayıtlı bir karara kadar geçen gün sayısı.
• İnceleme yorumlarınızın gerekçe içeren payı (yirmi tane örnekleyip sayın).
• Dolaşımdan sonra köklü yeniden yazım gerektiren öneriler; düşen bir sayı daha iyi ön hizalamaya işaret eder.
• Yazılı bir güncellemeden sonra yöneticinizin sorduğu açıklayıcı sorular; düşüş sinyaldir.
• Sizin bulunmadığınız bir sohbette dokümanınıza ya da standardınıza atıf yapan ekipler.
• Şirketinizin basamağında artık somut bir artefakt gösterebildiğiniz satırlar.

Yazılı artefakt, organizasyonunuz karar verdiği şeyi okuduğu ve etkilemeye çalıştığınız karar bir sayfayı hak edecek kadar pahalı olduğu sürece varsayılan olarak kalır. Kararlar odada veriliyorsa önce ön hizalama sohbetine, dokümanlar zaten varken ekibin dışında kimse okumuyorsa daha kısa yüzeylere (güncellemeler, inceleme yorumları, sorular) yönelin. İlk adım her durumda aynıdır: bu hafta vermek üzere olduğunuz bir kararı alın, dört cümlelik özetini yazın ve etkilediği insanların göreceği yere bırakın.

Kaynaklar#

• Dropbox Engineering Career Framework: IC4 Software Engineer (yeni sekmede açılır) - Dropbox’ın açık çerçevesi her seviyeyi İletişim ve Etki üzerinden puanlar; IC4, kendi ekibinizin ötesinde etki beklemeye başladığı seviyedir.
• Dropbox Career Framework: IC5 Staff Software Engineer (yeni sekmede açılır) - Staff seviyesinde onay alma, ekipler arası yol haritası etkisi ve rahatsız edici sohbetleri yürütme beklentileri.
• GitLab Engineering Career Framework (yeni sekmede açılır) - Her mühendislik seviyesinde liderlik, teknik ve değer yetkinliklerini listeleyen, Senior ve Staff için iletişim beklentilerini adlandıran, tamamen açık bir matris.
• Rent the Runway Engineering Ladder (yeni sekmede açılır) - Teknik Beceri, İşi Bitirme, Etki ve İletişim ve Liderlik’ten oluşan dört sütunlu modeli yaygınlaştıran 2015 tarihli basamak.
• Design Docs at Google - Malte Ubl (yeni sekmede açılır) - Tasarım dokümanının ne işe yaradığı, hangi bölümlere ihtiyaç duyduğu ve ne zaman yazmaya değmediği.
• Present to Executives - StaffEng, Will Larson (yeni sekmede açılır) - SCQA açılışı, toplantı öncesi ön hizalama ve teknik önerileri yönetim karşısında batıran anti-pattern’ler.
• The Staff Engineer’s Path - Tanya Reilly (yeni sekmede açılır) - Staff rolü için pratik bir el kitabı; başkalarının gerçekten kullanacağı dokümanlar yazmaya dair kapsamlı bölümler içerir.
• Being Glue - Tanya Reilly (yeni sekmede açılır) - Ekipleri ayakta tutan koordinasyon işine ad veren ve neden bu kadar sık ödüllendirilmediğini açıklayan konuşma.
• How to Write Code Review Comments - Google Engineering Practices (yeni sekmede açılır) - Google’ın, geliştirici yerine koda yorum yapma rehberi; eşleştirilmiş kötü ve iyi örneklerle.
• How to Handle Reviewer Comments - Google Engineering Practices (yeni sekmede açılır) - İncelemenin yazar tarafı: eleştirel geri bildirimi kişisel bir hüküm gibi almadan nasıl karşılanır.
• Amazon 2017 Letter to Shareholders (yeni sekmede açılır) - Amazon’un altı sayfalık anlatı notu kültürünün ve iyi bir notun ne kadar iterasyon gerektirdiğinin herkese açık tarifi.
• Amazon Leadership Principles (yeni sekmede açılır) - “Have Backbone; Disagree and Commit” ilkesinin kaynağı; yapılandırılmış itirazın ardından taahhüdün en net kamusal ifadesi.
• Becoming a Better Writer - Gergely Orosz (yeni sekmede açılır) - Hızlı büyüyen startup’lardaki ve büyük teknoloji şirketlerindeki mühendislerin neden çoğu zaman koddan çok kelime yazdığı ve zayıf yazının belli bir seviyenin üzerinde ilerlemeyi nasıl frenleyebileceği. Önizleme ücretsiz; tam yazı abonelere özel.
• How to Ask Good Questions - Julia Evans (yeni sekmede açılır) - Özgül sorular sormaya ve mevcut anlayışınızı önce söylemeye dair kısa, pratik bir rehber.
• The Engineer/Manager Pendulum - Charity Majors (yeni sekmede açılır) - Karşı ağırlık argümanı: teknik güvenilirlik, liderlik üstlenirken uygulamalı işe yakın kalmaktan gelir.