Startup CTO El Kitabı

Startup CTO El Kitabı

Yüksek performanslı mühendislik ekipleri için temel beceriler ve en iyi uygulamalar

Giriş

• Her zaman öğrenmek: Yazar, çocukluğundan beri bilgisayarlara ve yazılım programlamaya tutkuyla bağlıydı ve bu sayede sürekli öğrenmenin önemini fark etti. Teknik lider olarak başarılı olmak için durmadan öğrenmek ve gelişmek önemlidir.
• Startup teknik liderinin ikilemi: Çoğu startup'ta teknik kurucu ortak bulunur; bu kişiler ilk kod tabanını yazar ve ilk mühendisleri işe alır. Ancak ekip büyüdükçe teknik liderin yönetim rolüne geçmesi gerekir ve bu süreçte liderlik becerileri yetersiz kalabilir.

Yazar hakkında

• Yazar, çeşitli startup'larda deneyim kazandı ve teknik lider olarak görev yaptı. Farklı startup'lardaki deneyimleri sayesinde teknik liderlik için gerekli çeşitli becerileri ve zorlukları anlamaya başladı.

Bu kitap nasıl kullanılır

• Bu kitap, yazılım mühendisliği ekiplerini yöneten liderler için bir başvuru kaynağıdır ve çeşitli konuları birbirinden bağımsız bölümler halinde ele alır. Her bölüm konuyu tanıtır, genel bir çerçeve sunar ve en iyi uygulamaları ortaya koyar.

İş süreçleri

• İş süreçlerini açıklayarak problem çözme için bir başlangıç noktası sunar. Süreçlerin, ekibin ve şirketin ölçeğine göre uyarlanması ve genişletilmesi gerekir.

İnsan ve kültür

Yönetimin temel ilkeleri

• Yönetimin altın kuralı: Ekibin performansı, yöneticinin performansını ölçmenin ölçütüdür. Ekip üyelerinin ellerinden gelenin en iyisini yapabilmesi için onları desteklemek gerekir.
• Profesyonel beceri ağacı: Teknik liderlik için yalnızca teknik becerilere değil, yönetim becerilerine de yatırım yapmak gerekir.

Sürekli iyileştirme

• Kaizen: Hem ekip hem de bireyler sürekli iyileştirmeyi hedeflemelidir. Hatalar, gelişim fırsatı olarak görülmelidir.

Koçluk

• Yönetici, ekip üyelerinin en iyi performanslarını ortaya koyabilmeleri için yardımcı olan bir koç rolünü üstlenmelidir.

Yönetim mentoru bulmak

• Liderlik dönüşümü için bir yönetim mentoru bulmak önemlidir. Uygun bir mentor aracılığıyla liderlik becerileri geliştirilebilir.

1:1 görüşmeler

• 1:1 görüşmeler, ekip üyeleriyle ilişki kurmak, onların güçlü ve zayıf yönlerini anlamak ve en iyi performanslarını sergilemelerine yardımcı olmak için bir fırsattır.

Skip-level görüşmeler

• Düzenli olarak yöneticinin doğrudan bağlı çalışanlarıyla görüşerek farklı bakış açıları toplanabilir ve bu sayede iş geliştirilebilir.

Yöneticiler için koçluk

• Orta kademe yöneticilerin performansı, organizasyonun performansı açısından kritiktir. Sürekli eğitim ve destek yoluyla yöneticiler yetiştirilmelidir.

Mühendislerle 1:1 görüşmeler

• Mühendislerle yapılan 1:1 görüşmeler, onların karşılaştığı sorunları dinlemek ve çözüm bulmalarına yardımcı olmak için bir fırsattır. Görüşmenin amacı net olmalı ve verimli bir diyalog yürütülmelidir.

[GN⁺]

Hacker News yorumları

• Bu tür belgeleri okurken genelde önce derinlemesine bildiğim bölüme gider, ne dediklerine bakarım. Burada PCI DSS veya SOC 2 denetimlerine hazırlanıp bunları yürütmenin genellikle 6-12 ay sürdüğü, bu yüzden sertifikasyonu son dakikaya bırakmamak gerektiği söyleniyor; ama startup’lara neredeyse tam tersini tavsiye ederdim.
  Özellikle SOC 2 tasdiki almak kolaydır ve satın alma siparişi gündeme gelmeden önce proaktif olarak para harcamak israftır. Elbette single sign-on ayarları veya korumalı Git branch’leri gibi sonradan tasdikin temelini oluşturacak şeyleri erkenden yapmak iyi olur; ama bunlar, SOC 2 almayı planlamasanız bile zaten yapmanız gereken temel iyi uygulamalara daha yakındır. Büyük bir müşteri istemiyorsa SOC 2 yapmaya gerek olmadığını düşünüyorum. Bu belgenin başka bölümlerini de birilerinin kontrol etmesi iyi olur.

  • İyi bir yaklaşım. Veritabanı tarafını arattım, genel olarak fena değildi. Ancak 2025’te bir startup’ın SQL ve NoSQL konusuna odaklanmasına gerek yok gibi görünüyor. Popüler SQL veritabanları JSON’u iyi desteklediği için mühendislerin daha aşina olduğu PostgreSQL veya MySQL kullanıp, yedekleme ve replikasyonu üstlenecek CloudSQL ya da RDS kullanmak yeterli.
    BI için bir okuma replikası ve düzgün bir görselleştirme aracı eklerseniz epey uzun süre idare edebilirsiniz; Snowflake gibi bir şeye 5-6 haneli rakamlar harcayana kadar fazlasıyla yeter.
  • Deneyimime göre, erken aşama startup’larla çalışmaya istekli olup SOC 2 raporu isteyen şirketler, teknik sorumlu karşı taraftaki IT ekibiyle görüşüp yetkinliğin yeterli olduğuna onları ikna edebildiği sürece, sözleşmeye 6 ay içinde SOC 2 Type 1 alınması maddesini koyup ilerlemekte genellikle sorun görmüyor.
  • Muhasebe ve tedarik zinciri süreçlerinin kurumsal ERP içinde olduğu durumlar için saygıyla karşı çıkıyorum. Denetlenemez süreçleri sonradan geri çevirmek çok fazla zaman ve para alıyor; bu sırada işin de dönmeye devam etmesi gerekiyor. Bu özel durumda, ilk günden itibaren denetlenebilir hale getirmek bence daha ucuz ve daha iyi.
  • Bu tavsiyenin geçerliliği sektöre göre epey değişebilir. Kişisel tanımlanabilir bilgi işleyen bir B2B ürün satıyorsanız, satış sunumu toplantılarında gülünç duruma düşmemek için SOC 2 fiilen gerekli.
    Finansman durumuna bağlı olarak Secureframe gibi otomatik SOC 2 uyumluluk kontrol listesi hizmetlerini kullanmanın maliyeti birkaç bin dolar seviyesinde olabilir; bunlar yalnızca iyi uygulamaları takip etmenizi sağlamakla kalmaz, aynı zamanda işleri SOC 2’ye özgü şekilde düzenleyip denetimi de kolaylaştırır. Zaten uyumsuz süreçlerin derine yerleştiği bir organizasyonu SOC 2 yoluna sokmak için harcanacak geliştirme ve proje yönetimi zamanıyla kıyaslandığında büyük bir yatırım değil.
  • Uyumluluk konusunu pek bilmiyorum ama bu kulağa oldukça tuhaf geliyor. SOC 2’ye şöyle bir bakınca, denetimden önceki birkaç ay boyunca muazzam bir kanıt toplama gerekiyor; önceden zaman harcamadıysanız sonradan neyi hazır etmeniz gerektiğini nasıl bileceğinizi anlamıyorum.
    SOC 2 tasdikinin kolay alınabileceği sözü de bu konuda başkalarından duyduklarımın tam tersi. Genelde bunun çok zor ve zaman alıcı olduğunu duydum; neyi kaçırdığımı merak ediyorum. Gerçekten kolaysa yanılıyor olmayı isterim.

• VP veya CTO olunca kod yazmayı bıraktığınız sözüne sıkça rastlıyorum. Yönetim becerisinin kodlama becerisi olmadığını biliyorum, ama insanların neden klavyeyi bırakıp ilk süper güçlerini boşa harcadığını anlamakta zorlanıyorum.
  Baştan sona teknik bir CTO olarak kalabilirsiniz. Ekibe ve şirkete aktif katkı, bakım ve on-call desteği gereken bir hizmet gibi davranmalı; aynı zamanda hem tek başınıza hem de ekiple birlikte bizzat ellerinizi kirleterek üretmelisiniz.

  • VP/CTO seviyesinde koda katkı yapacak ve bakımını üstlenecek zamanınız olmaz. Zamanınız varsa o unvan muhtemelen semboliktir; örneğin 3 kişilik bir startup ekibindeki “CTO” gibi.
    Asıl sorun, kariyerin başlarında kod yazmaya zamanı olmayan bir rol üstlenmektir. Whiteboard’a sadece kutular çizip toplantıdan toplantıya koşan mimar rolleri ya da gerçekte yönetim rolü olup adına “tech lead” denmiş pozisyonları kabul etmek gibi. Kod yazmamaya alışır ve birkaç yıl sonra yeni iş aramak zorunda kaldığınızda, programlama kariyerinizin önemli bir kısmını kod yazmadan geçirdiğiniz gerçeğiyle yüzleşerek kodlama pozisyonları için mülakata girersiniz. Birçok kişi için refleksler hızlı geri gelmez.
  • Benim deneyimimde mesele, gün içinde yalnızca o kadar zaman olmasıydı. 7 yıl boyunca doğrudan ve dolaylı olarak sorumlu olduğum kişi sayısı 20-25 civarındaydı ve kodda işe yarar bir şey çıkaracak zaman gerçekten çok azdı.
    Zamanımı, başkalarının çözemediği problemleri çözmeye harcamak çok daha iyiydi. Ara sıra çok basit değişiklikler üstlenip süreçlerimizden bizzat geçer, nereleri iyileştirebileceğimizi görürdüm. Geceleri veya hafta sonları kod yazmaya devam ettim ama aynı his değil; zaman geçtikçe ister istemez biraz paslanıyorsunuz. Yine de izin döneminde bütün gün ellerimi kirleterek kod yazmak gerçekten keyifliydi.
  • Sadece bireysel katkı sağlayan biri değilseniz başka öncelikler ortaya çıkar. Bu yüzden bireysel katkı işleri her an kesintiye uğrayabilir. Böyle olunca kritik yola yakın işleri üstlenemezsiniz; üstlenirseniz de ya başkalarını engellersiniz ya da işi devretmek zorunda kalırsınız.
    İnceleme veya tasarım toplantıları yapılabilir, ama çekirdek işleri üstlenirseniz sonunda sorun çıkar.
  • Tek bir doğru olduğunu sanmıyorum, ama bir noktadan sonra VP/CTO’nun koda katkısından çok bir sonraki kilit mühendisi işe almak, rekabette öne geçmek için teknoloji yol haritası oluşturmak veya mühendislik organizasyonunu şirketin geri kalanıyla hizalamak çok daha büyük kaldıraç etkisi yaratır.
    VP/CTO’nun yazabileceği kodu ekipten başka biri de yazabilir, hatta belki daha iyi yazabilir. Buna karşılık saydığım diğer işleri şirkette en iyi yapma ihtimali olan kişi VP/CTO’dur. Ekip ve şirket için daha önemli işler uğruna uygulamalı teknik işlerin çoğunu bırakmak oldukça makul bir karardır.
  • Son CTO rolüm 40 kişilik bir ekipti ve ilk günden tamamen aşırı yük altındaydım. Zaman yönetimim iyi sayılır, buna rağmen böyleydi. Mümkün olsa zamanımın %50’sini programlamaya ayırmak isterdim; ama buna zaman yoktu ve devredebileceğim bir destek yapısı da yoktu, bu yüzden onu da bizzat zorlukla kurmam gerekti. Zaten zamanımın olmamasının bir nedeni de buydu.
    Kod yazmaya devam etme fikri güzel, ama genellikle size ücret ödenmesinin nedeni bu değildir. Kendimi çok güçlü bir geliştirici olarak görüyorum, ama böyle geliştiriciler CTO maaşından daha düşük maliyetle bulunabilir. Daha pahalı bir CTO’nun bu işi yapması verimsizdir. Not olarak, birkaç yıl sonra bireysel katkı rolüne geri döndüm ve kariyerimin kalanını da böyle sürdürmeyi düşünüyorum.

• Senkron sohbet diye bir şey olmadığını söylemek isterim.
  Senkron olması gerekiyorsa bunu sohbet penceresinde yapmamalısınız. En azından “birkaç dakika boyunca gerçek zamanlı sohbete odaklanalım” diye anlaşmadıysanız. Uzaktaysanız telefon edin, aynı ortamdaysanız yüz yüze konuşun. Sohbete bir mesaj bırakıp anında yanıt beklememelisiniz.

• “İki ekip” düzeninde hiç kırgınlık yaşanmayan örnekler olup olmadığını merak ediyorum. İnsanların doğal olarak gelecek ekibine geçmek istemediği durumlar da olmuş mudur, emin değilim.
  Kâğıt üzerinde iyi bir fikir gibi duruyor ama pratikte gerçekten iyi işleyeceğine inanmak zor. Gördüğüm en yakın biçim, tasarım sistemi ve bileşenler gibi hizmetler üretip diğer ekiplerin kullanmasını sağlayan bir kütüphane ekibiydi.

  • Önceki iş yerimde, desteği bitmek üzere olan bir sürüm için şirketin çok uzun süreli uzatılmış destek sattığı bir on-premises ürün sürümü vardı. Küçük bir ekip, sanırım yaklaşık 3 kişi, yalnızca o sürümün desteklenmesini, pipeline’ın çalışmasını ve gerekirse büyük düzeltmelerin de dağıtılabilmesini sağlamaktan sorumluydu.
    Bu sorumluluğu yerine getirdikleri sürece kalan zamanda şirket için değerli gördükleri işleri yapmakta özgürdüler. Oldukça iyi bir anlaşmaydı. Diğerleri, bu küçük ekibin kirli işi üstlenmesine minnettardı; bakım ekibi de kalan zamanda hep canlarını sıkan şeyleri düzeltebildiği ya da araştırma yapabildiği için memnundu. Ayrıntıları unuttum ama oldukça güzel iyileştirmeler ve araştırma sonuçları çıktığını hatırlıyorum. Ekipteki insanların çok yetenekli ve kendi kendini yöneten kişiler olması da başarıya yardımcı oldu, ama maliyeti de daha yüksekti.
  • Kitap bu soruna çözüm olarak düzenli rotasyon öneriyor gibi. Microsoft blog yazısı, her hafta ekip üyelerinin bir kısmını iki ekip arasında değiştirmeyi ve müşteri ekibini geçici ekip olarak tanımlamayı öneriyor.
    Gerçekte tamamen ayrılmış ekiplerin iyi çalıştığı birkaç yer gördüm. Oyunlarda motor ekibi ile oyun ekibini düşünebilirsiniz. Eski rollerimden birinde, oyun ekibinin içinde bile 6–12 hafta süren bir özelliği üstlenip yayınladıktan sonra bakım, güncelleme ve teknik borçla ilgilenirdik. Yeni yayınlanan şey ana odak olurdu ama önceki işlere dönmek için de zaman vardı; diğer ekip de aynı döngüde olur, 6–8 hafta sonra yeni bir özelliğe onboarding yapardı; bu böyle tekrarlanırdı.
  • Eskiden iki ekipli bir sistemi denemiştik. Özellik geliştirmeyi Red Team, kararlılık ve hata düzeltmelerini Blue Team üstleniyordu.
    Bunu sabit ekipler olarak değil, insanların her sprint’te, yani 2 haftada bir gidip geldiği bir iş akışı olarak ele aldık. Yaklaşık 3 ay iyi işledi ama sonra uygun olmamaya başladı; o sıralarda organizasyon büyüdü ve ekipleri iş yetkinlikleri ya da domain’ler etrafında yeniden yapılandırdık.
  • Benzer şekilde, mühendislerin birer hafta destek ve hata raporlarıyla ilgilendiği bir nöbet sistemi denemiştik. Tamamen ayrılmış “iki ekip” tuzaklarının epeyce önüne geçebildik. https://news.ycombinator.com/item?id=43337703#43339972 adresinde biraz daha yazmıştım.
  • “Müşteri ekibi” yeterli kaynağa sahipse ve ödüllendirme de uygunsa, özellikle “gelecek ekibine” geçmek istemezdim gibi geliyor. Ama ekipleri ayırmasanız bile bakım işleri genelde kaynak bulamazken yeni özellikler tüm ilgiyi ve kaynakları alıyor. İkiye ayırmak bunu daha da kötüleştirebilir gibi görünüyor.

• Bu tür materyallerin iyi yanı, İncil gibi kullanılmaları değil; sorumlulukları ve ilgi alanlarını genişçe taramaları.
  Harika bir danışmanınız yoksa ya da gerçekten çok iyi birinin altında çalışmadıysanız, bu konuma geldiğinizde kimse yanınıza oturup dikkat etmeniz gereken şeylerin listesini vermez. Her bölüm “Bizim cevabımız ne?”, “Katılıyor muyuz?”, “Sürecimiz daha mı iyi?”, “Neyi kaçırıyorum?” diye sordurduğu için faydalı.

• “İki ekip” ayrımının bu kadar açıkça yazılması ilginç. Bu, düzgün bir şey yayınlamanın maliyeti aşırı büyüyene kadar sürekli yayın yapmayı sağlamanın harika bir yolu.
  Yazılımı ilk yapan insanlara dönen geri bildirim döngüsünü koparırsanız, onlar kısa süreliğine daha mutlu olur, başkaları da kısa süreliğine daha mutsuz olur. Sonra özellik ekibi bir daha asla rahatsız edilmek istemez hale gelir; müşteri ekibi ise hiçbir şeyi doğru düzgün düzeltecek kaynak alamaz.
  Daha kötüsü, özellik ekibinin kod satırı göndermek dışında hiçbir şey öğrenmemesidir. Zamanla işlerin yavaşlamasının ve pahalılaşmasının nedeni, iyi yazılım geliştirmenin tek uygunluk fonksiyonunu, yani olumsuz geri bildirimi geliştirmenin kaynağına yeniden entegre etme sürecini ortadan kaldırmanızdır. Gerçek bir CTO liderlik el kitabı, “Geliştiricilerin yayın yaparken de iyileşmesine yardımcı olmak sizin sorumluluğunuzdur ve geliştiriciler bunu her zaman sevmeyecektir” diye açıkça söylemelidir.

  • “Özellik ekibinin müşteri destek işleriyle bölünmeden geleceğe %100 odaklanmasını sağlar” sözü, daha çok özellik ekibinin yol açtığı felaketten tamamen habersiz biçimde gemi buzdağına tam çarpana kadar devam etmesini sağlamak anlamına geliyor.
    Satışın desteklediği özellik ekibi ile müşteri temsilcilerinin desteklediği bakım ekibi arasında merge çatışmaları da çıkar. “Müşteri ekibi” sonradan çıkılan bir aşama gibi tasvir edildiği sürece öncelik savaşını hangi tarafın kazanacağı bellidir. “Bireysel mühendisler, özellikle de junior’lar için öğrenme ve gelişme adına başka bir yol” ifadesi de sonunda “senior’lar pisliği temizlemek istemediği için junior’lara yaptırıyoruz” gibi duyuluyor.
  • Bununla bağlantılı olarak, çalıştığım şirketlerden platform ekibi olanlar genelde aşırı mühendisliğe yakalanmıştı. Burada platform ekibi, araçları, pratikleri ve ortak kodu yöneten üçüncü bir destek ekibi gibi bir şey anlamına geliyor.
    Bu ekipler, özellik dağıtmayı ve hata düzeltmeyi küçümseyen, sorunları aşırı soyutlama eğilimindeki insanları kendine çekme eğiliminde oluyor. Hataları düzeltmek yerine hataların en baştan oluşmasını engelleyeceğiz diye giderek daha karmaşık soyutlamalar yapıyorlar; sonuç da malum.
  • Bu PM’in işidir. Müşterilerle çalışıp geri bildirime dayanarak tüm özelliklerin nasıl birbirine uyacağına dair vizyonu belirleyecek bir kişiye ya da birkaç kişiye ihtiyaç vardır.
    Müşteriler, özellikle de teknik olmayan müşteriler, tutarlı bir ürün vizyonuna sahip değildir; çoğu zaman başka planlardan bağımsız olarak yalnızca o anki düzeltmeyi isterler. Müşteriler birbiriyle iletişim kurmadığı için geri bildirimler de çelişebilir. Bu yükü geliştiriciye bindirirseniz geliştirici, kod tabanını bilme ve iyi bakımını yapma teknik yetkinliğine ek olarak tüm iletişimi de yönetmek zorunda kalır; ayrıca tüm geliştiricilerin düşünceli kararlar verebilmek için aynı tutarlı vizyona sahip olması gerekir. Günümüzde geliştiricinin altyapıyı da yönettiği bir rolde bu, pratikte iki üç işi bir kişinin yapması demektir.
  • Bunu telafi etmek için her sprint’te ya da birkaç sprint’te bir ekip değiştirirdik. İnsanlar daha çeşitli deneyim kazanıyor, çok hatalı özellikler yaptıklarında sonunda bunları bizzat düzeltmek zorunda kaldıkları için geri bildirim almaya devam ediyorlardı.
    İnsanlar bu yöntemi çok daha fazla sevmiş gibi görünüyordu. Çünkü sürekli sadece hata düzeltmekten yorulmuyorlar, sizin isabetle söylediğiniz geri bildirim kopukluğundan da kaçınılıyordu.
  • Geliştiriciler, yaptıkları yazılımı işletmeli ve bakımını yapmalıdır. İlke bu kadar basit.

• Bu noktada kaç kez mülakat yaptığımı sayamayacak durumdayım; bu yüzden buna biraz katılmak zor. Zorluklardan biri, başvuru aşamasında adayların çok fazla olabilmesi ve bu aşamada adayla genellikle işe alım ekibinin etkileşime girmesi.
  Örnekteki soruları koymak sorun değil, ama niteliksiz adayları elemek için evet/hayır ya da ölçek tipi olmayan sorular gerekiyor. Ben net bir cevabı olan çok basit soruları tercih ederim. JavaScript’te “çok rahatım” deyip ===’ın ne olduğunu bilmeyen şaşırtıcı derecede çok kişi var. Bu yüzden “JavaScript’in katı eşitlik operatörü nedir?” gibi sorular sorarım. Her JavaScript programcısı bunu bilir, ama tek bir böyle soru bile aday havuzunun %50’sini eler ve kuruluşun muazzam zaman tasarrufu yapmasını sağlar.

• Kültür uyumundan çok söz ediliyor, ama bunun önemli bir kısmı şirkete zarar veren gizli ayrımcılık katmanlarını yukarı çekiyormuş gibi görünüyor. Kültürel açıklığın bir başarı faktörü, ayrımcılığın ise ters yöne götüren bir şey olduğunu düşünüyorum.
  “En iyi liderler başarı oranını takip eder, işe alım hatalarını kabul etmekten korkmaz; yavaş işe alır, hızlı işten çıkarır” cümlesini görünce, JWZ’nin (Jamie Zawinski) bu siteyi işaret eden referrer header’ını tespit ettiğinde gösterdiği görseli paylaşmak istiyorum. Jamie Zawinski’nin Y Combinator hakkında ne dediğini Google’da arayabilirsiniz. Kendisi ayrıca Netscape’in Netscape Navigator’ı açık kaynak olarak yayımlama kararında ve o tarayıcı render motoruna uzanan çalışmaların çoğunda pay sahibi olan kişidir. Firefox’un var olmasının nedeni de bu.

  • “Kültür uyumu”nu gizli ayrımcılık olarak görmek alaycı bir yorum; benim gördüğüm durumlarda daha çok adayın hoşlanmayacağı bir işi üstlenmesini engellemek için kullanıldı.
    İlk çalıştığım yerlerden birinde, işe alım kriterlerinde kültür uyumu denebilecek her şeyi yasaklamaya çalışmışlardı. Sonuç olarak bazı kişiler işe girer girmez şirketten nefret etti ve birkaç hafta ya da birkaç ay içinde ayrıldı. Bir aday planlama ve öngörülebilirliğe vurgu yapmış, önceki şirketlerinin çok hızlı hareket ettiğinden şikâyet etmişti. Biz bir startup’tık ve beklendiği gibi şirketten nefret etti. Ama işe alım kararı sürecinde bu tür kaygıları dile getiremiyorduk. Çünkü bunun “kültür uyumu” olduğu ve ayrımcılığa yol açabileceği düşünülüyordu. Benzer şeyler birkaç kez daha yaşandıktan sonra o politika sessizce ortadan kalktı ve mühendislik kültürüyle uyumluluğu yeniden değerlendirebilir hale geldik.
  • Her işe alım süreci ayrımcılık yapar. Önemli olan hangi özellikleri avantajlı ve dezavantajlı kıldığı ve neyi dışarıda bıraktığıdır.
    “Kültür uyumu” çoğunlukla iletişim verimliliği ve yüksek güven elde etmek karşılığında düşünce çeşitliliğinin bir kısmından vazgeçilen bir takastır. İnsanlar nasıl davranmaları gerektiğini ve birbirlerinden ne beklemeleri gerektiğini zaten bildikleri için çok fazla yönerge koymaya gerek kalmaz; ancak grup düşüncesine ve ilgili bilişsel önyargılara karşı daha savunmasız hale gelinir. “Bu gemide gökkuşağının tüm renkleri var, ama bizim Klingon’umuz bile Klingonların kötü olduğunu düşünüyor” gibi.
  • Konunun dışına sapmayı kabul edip arama yaptım, ama ilk sayfadaki sonuçların tamamı Hacker News’te Jamie Zawinski’den bahseden yorumlardı; orada vazgeçtim. Bu yüzden ne demek istediğini söylersen iyi olur.

• “Açıklama videolarından oluşan bir kütüphane oluşturun” tavsiyesinin iyi olup olmadığından emin değilim. UI ya da animasyon gibi belirli şeyler için mantıklı olabilir.
  Ama genel olarak metin okumak, video izlemekten daha verimlidir. Acele olduğunda metinde önemli bölüme gitmek de videoya göre çok daha kolaydır.

  • Bazıları videoyu sever, bazıları metni sever. İkisi de emek ve etki gerektiren yatırımlardır. Artık üretken yapay zeka sayesinde ikisini de oluşturmak kolaylaştı.