Nazik Mühendislik

Nezaket nedir?

Kind is about being invested in other people, figuring out how to help them, meeting them where they are.

Nezaket, başka insanlara emek vermek, onlara nasıl yardımcı olunacağını bulmak ve onları bulundukları yerde karşılamaktır.

— Tanya Reilly, Continuous

Nezaket, Tanya Reilly’nin yukarıda söylediği gibi, insanlara emek vermek demektir. Bu, yalnızca kibar olmak değil; karşımızdakinin yerine kendini koyup onun duygularını ve arka planını anlamak anlamına gelir. Her durumda sihirli bir çözüm olmasa da, birçok sorunun çözülmesine yardımcı olabilir.

Şefkat

• “Profesyonel olmak”ın ötesine geçip işinize sahip çıkın.
• Açık ve insani davranarak güven inşa edin.
• İnsanlarla doğrudan ilgilenin ama bunu düşünceli bir özenle yapın.
• Beyaz yalanlar kötü olmayabilir ama insanların gelişmesini sağlayamaz.
• Şefkati elden bırakmayın; iyi davranışları takdir edin ve geliştirilebilecek noktaları belirtin.

Asenkron (async) iletişim

• Değişim söz konusu olduğunda yalnızca “ne?” ve “nasıl?”ı değil, “neden?”i de daha iyi anlamaya çalışın.
• Kötü niyet ya da yetersizlik varsaymayın.
• Sert veya tartışma yaratmaya açık ifadeler yerine, zihni açık sorular sorun.
• Eleştiriden önce, açık etiketlerin kullanılması önemlidir.
• Fazla eleştiri, işe daha büyük zarar verebilir.
• Görüş çoksa, iletişimi sıralı bir biçime dönüştürün.

Psikolojik güvenlik

• Takımdan veya çalışma arkadaşlarınızdan ilk olarak siz geri bildirim isteyin.
• Geri bildirimin yapısı basittir:
  • İyi gidenler
  • Kötü gidenler
  • Sonrasında yapılacaklar
• İnsanların geçmişlerini, hikâyelerini ve kişisel tercihlerini açık biçimde kabul edin.
• Toplantılara veya belgelere büyük katkı veremeyen kişilere dikkat edin ve onların seslerini duyurabilecekleri yollar bulun.
• İnsanların kendilerini doğru hissettikleri herhangi bir biçimde ifade edebilmeleri için ses çıkarın.
• Bireysel başarısızlıklar çoğu zaman aslında süreç, ortam veya iş akışındaki bir başarısızlıktan kaynaklanabilir.
• Birlikte başarılı oluruz, birlikte başarısız oluruz.
• Her “başarısızlık” veya olay, büyümek ve öğrenmek için bir fırsat olarak kutlanmalıdır.
• Yeniliği teşvik etmek için, insanların risk almasını, meydan okumasını ve bunun güvenli olduğunu hissetmesini desteklemeliyiz.

Geri bildirim / eleştiri

• En baştan değerlendiren kişi değil, önce değerlendirilen kişi olun.
• Bunu kişisel bir meseleye dönüştürmeyin.
• Geri bildirim veya övgü verirken mümkün olduğunca somut ve kapsamlı olmaya çalışın.
• Birine eleştirel geri bildirim veriyorsanız, bir çözüm de önerin.
• Kendi geri bildirim tercihlerinizi anlayın.
• Dinleyin, anlayın ve ardından geri bildirim veren kişiye teşekkür edin.
• Hemen tepki vermeyin; düşüncelerinizi toparlamak ve geri bildirimi işlemek için zaman ayırın.
• Açıklama veya örnek isteyin.
• Geri bildirim vermenin üç unsurunu hatırlayın:
  • Duygu
  • Güvenilirlik
  • Mantık
• Kendi duygularınızı değil, dinleyenin duygularını dikkate alın.
• Yetkinlik ve tevazu gösterin.
• Nasıl çalıştığınızı ve sonuca nasıl ulaştığınızı gösterin.

---

• Teknoloji sektöründe zehirli bir üslup sorunu var, bunu düzeltelim!

[arfwene]

Bariz bir şey ama uygulaması zor..

[aster]

Yukarıdaki materyale dayanarak geliştirme süreçlerinde nazik mühendislik nasıl uygulanabilir?
Buna, yapay zeka yardımıyla oluşturduğum KDD (Kindness Driven Development) diyebiliriz.

Kod yazımı

• Yorumları ve dokümantasyonu "Neden?" sorusuna odaklanarak yazın. Kodun var olma sebebini ve arka planını açıklamak önemlidir.
• Karmaşık mantıkta, diğer geliştiricilerin kolayca anlayabilmesi için alan terimlerini kullanan değişken ve fonksiyon adları kullanın.
• Yeni teknoloji veya pattern'ler kullanıma alınırken ekip arkadaşlarının öğrenme eğrisini göz önünde bulundurun.
• Legacy code'u suçlamayın. O dönemin de kendi kısıtları ve bağlamı vardı.
• Gelecekte bakım yapacak kişiler için edge case ve failure case işlemlerini dokümante edin.
  Mimari tasarım
• Sistem tasarlarken operasyon ekibi ile QA ekibinin bakış açısını da hesaba katın.
• İzleme ve debug işlemlerini kolaylaştırmak da nazik tasarımın bir parçasıdır.
• Ölçeklenebilir bir tasarım, gelecekteki ekip arkadaşlarına gösterilen bir özen biçimidir.
• Teknik borcu yönetirken, tamamen ortadan kaldırmayı değil "yönetilebilir seviye"yi hedefleyin.
• Yeni özellik eklemeyi kolaylaştıran bir yapı kurmak önemlidir.
  Kod incelemesi
• Review isterken yapılan değişikliklerin bağlamını yeterince açıklayın.
• "Bunu şöyle yapsak nasıl olur?" gibi öneri odaklı geri bildirimler kullanın.
• Olumlu kısımları da mutlaka belirtin. "Bu bölüm gerçekten çok temiz görünüyor."
• Alternatif önerirken nedenini de birlikte açıklayın.
• Acil olmayan iyileştirmeleri ayrı bir issue olarak kaydedip mevcut PR'ın kapsamına saygı gösterin.
  Test kodu
• Test başarısız olduğunda net hata mesajları sağlayın.
• Test case'leri aynı zamanda dokümantasyon işlevi de görür. İş kurallarını iyi açıklayan testler yazın.
• Diğer geliştiricilerin kolayca test ekleyebileceği bir yapı oluşturun.
• Test verilerinde anlaşılması kolay gerçek örnekler kullanın.
• Test ortamı kurulumunu otomatikleştirerek giriş eşiğini düşürün.
  Dağıtım ve operasyon
• Dağıtım script'lerine yeterli açıklama ve rehber ekleyin.
• Bir arıza yaşandığında debug sürecine yardımcı olacak log'ları önceden hazırlayın.
• Yapılandırma değişikliği gerekiyorsa etkisini dokümante edin.
• Yeni özellik yayınlarken rollback planını da birlikte hazırlayın.
• Operasyon rehberini yeni başlayan bir geliştiricinin bakış açısından yazın.
  Bilgi paylaşımı
• Sorun giderme deneyimlerini dokümante edip paylaşın.
• Yeni teknoloji devreye alınırken öğrenme materyalleri hazırlayıp paylaşın.
• Kod yazım rehberlerine "neden böyle yapmaya karar verildiği" bilgisini de ekleyin.
• Düzenli teknik paylaşım zamanlarıyla ekibin gelişimini destekleyin.
• Soru sormanın kolay olduğu bir ortam oluşturarak junior geliştiricilerin gelişimine yardımcı olun.

[bbulbum]

Bu, başlı başına ayrı bir yazı olarak da yazılabilecek kadar iyi bir içerik aslında haha

[laeyoung]

Gerçekten çok güzel!

[aer0700]

Gerçekten çok iyi bir yorum.