- Harika mühendisler, en iyi programcılar değil; kodun etrafındaki insanları, politikayı, koordinasyonu ve belirsizliği nasıl yöneteceğini öğrenmiş kişilerdir
- Bu içerik, teknolojiden çok projelerde ve ekiplerde tekrar tekrar görülen kalıplara odaklanıyor; kullanıcı problemlerini çözme, ekip işbirliği, kod kalitesi ve kariyer yönetimi gibi başlıkları kapsıyor
- Netlik, kıdemli mühendislerin temel niteliğidir ve zekice görünmek çoğu zaman sadece ek yüktür; ayrıca yazılmamış kodun en iyi kod olduğu yönünde paradoksal bir içgörü sunuyor
- Büyük organizasyonlarda hizalanma eksikliği, yavaşlamanın başlıca nedenidir; ayrıca bir ölçüm hedefe dönüştüğünde nasıl çarpıtıldığını göstererek organizasyon yönetiminin tuzaklarını ortaya koyuyor
- Uzun vadede zaman, paradan daha değerli bir kaynak haline gelir ve ağınız her işinizden daha uzun ömürlü olduğu için kariyerinizi bilinçli biçimde tasarlamanız gerekir
1. En iyi mühendisler, kullanıcı problemlerini çözmeye takıntılıdır
- Önce teknolojiye kapılıp sonra ona uygun kullanım alanı aramak caziptir; ancak en büyük değeri üreten mühendisler ters yönde çalışır: kullanıcı problemini derinlemesine anlayıp çözümü oradan türetirler
- Kullanıcı odaklılık; destek taleplerine zaman ayırmak, kullanıcılarla konuşmak, onların zorlandığı noktaları gözlemlemek ve kök nedene ulaşana kadar "neden" diye sormak demektir
- Problemi gerçekten anlayan mühendisler, zarif çözümün çoğu zaman beklenenden daha basit olduğunu sık sık fark eder
- Çözümle başlayan mühendisler ise onu gerekçelendirmek için karmaşıklık inşa etme eğilimindedir
2. Doğru olmak kolaydır; birlikte doğruya ulaşmak ise asıl iştir
- Her teknik tartışmayı kazanıp yine de projeyi kaybedebilirsiniz; ayrıca sürekli odadaki en zeki kişi olup sessiz bir hoşnutsuzluk biriktiren parlak mühendisler de görülür
- Bunun bedeli sonradan "gizemli yürütme sorunları" ve "garip direnç" olarak ortaya çıkar
- Asıl beceri doğru olmak değil; problemin etrafında hizalanmak için tartışmaya katılmak, başkalarına alan açmak ve kendi kesinliğinize şüpheyle yaklaşmaktır
- Güçlü fikirler, zayıf bağlılık: bunun nedeni inanç eksikliği değil, belirsizlik altında alınan kararları kimliğinizle birleştirmemeniz gerekmesidir
3. Eylem yanlılığıyla yayına çıkın. Kötü bir sayfa düzenlenebilir, boş bir sayfa düzenlenemez
- Mükemmellik arayışı felce yol açar; daha önce hiç inşa edilmemiş bir şeyin ideal mimarisini haftalarca tartışan mühendisler görülür
- Mükemmel çözüm, sadece düşünerek değil gerçeklikle temas ederek ortaya çıkar ve yapay zeka buna birçok yönden yardımcı olabilir
- Önce yap, sonra doğru yap, sonra daha iyi yap: çirkin bir prototipi kullanıcıların önüne koyun, dağınık bir tasarım dokümanı taslağı yazın, biraz utandıran bir MVP yayınlayın
- Bir haftalık gerçek geri bildirimden, bir aylık teorik tartışmadan daha fazlası öğrenilir; ivme netlik yaratır, analiz felci ise hiçbir şey üretmez
4. Netlik kıdemin işaretidir, kurnazlık ise ek yüktür
- Zekice kod yazma içgüdüsü mühendisler arasında neredeyse evrenseldir ve yetenek kanıtı gibi hissettirir
- Yazılım mühendisliği, işin içine zaman ve başka programcılar girdiğinde başlar; bu ortamda netlik, bir stil tercihi değil operasyonel riskin azaltılmasıdır
- Kod, arıza sırasında gece 2'de bakım yapacak yabancılar için yazılmış strateji notlarıdır; bu yüzden amaç zarafet değil, onların anlayışını optimize etmektir
- En saygı duyulan kıdemli mühendisler, zekice olmayı her seferinde netlikle takas etmeyi öğrenir
5. Yenilik; kesinti, işe alım ve bilişsel yük olarak geri ödenen bir borçtur
- Teknoloji seçimlerini, küçük bir "yenilik jetonu" bütçesi olan bir organizasyon gibi ele alın; pratikte standart dışı bir şeyi her benimsediğinizde bunlardan birini harcarsınız ve çok fazla kaldıramazsınız
- Mesele "asla yenilik yapma" değil; yalnızca benzersiz biçimde yenilik üretmeniz için ödüllendirildiğiniz yerde yenilik yapın demektir. Geri kalan her yerde varsayılan seçenek sıkıcılık olmalıdır
- Çünkü sıkıcı şeylerin bilinen arıza modları vardır
- "İş için en iyi araç", çoğu zaman "birçok iş için en az kötü araç" anlamına gelir; çünkü bir hayvanat bahçesi işletmek gerçek bir vergidir
6. Kod sizin adınıza konuşmaz, insanlar konuşur
- Kariyerin başlarında iyi işin kendi kendine konuşacağına inanılır; ama bu bir yanılgıdır, çünkü kod depoda sessizce durur
- Yöneticiniz bir toplantıda sizden bahseder ya da bahsetmez; iş arkadaşınız bir proje için sizi önerir ya da başkasını önerir
- Büyük organizasyonlarda kararlar, davet edilmediğiniz toplantılarda, sizin yazmadığınız özetler üzerinden, sadece 5 dakikası ve 12 önceliği olan insanlar tarafından alınır
- Siz odada yokken hiç kimse etkinizi ifade edemiyorsa, o etki fiilen isteğe bağlıdır; bu öz-pazarlama değil, değer zincirini herkes için, sizi de içerecek şekilde okunabilir kılmaktır
7. En iyi kod, yazılmasına gerek kalmayan koddur
- Mühendislik kültürü yaratmayı kutlar; ama kod silmek çoğu zaman sisteme kod eklemekten daha fazla iyileştirme sağlar, yine de kimse kod sildiği için terfi almaz
- Yazılmayan her kod satırı, debug edilmesi, bakım yapılması ve açıklanması gerekmeyen bir satırdır
- İnşa etmeden önce şu soruyu sonuna kadar zorlamak gerekir: "Ya sadece... yapmasak?" Bazen cevap "kötü bir şey olmaz" ise çözüm budur
- Sorun, mühendislerin kod yazamaması ya da yapay zekayla yazamaması değil; çok iyi yazabildikleri için önce yazmaları gerekip gerekmediğini sormayı unutmalarıdır
8. Ölçekte, hataların bile kullanıcıları vardır
- Yeterince çok kullanıcınız varsa gözlemlenebilir her davranış bir bağımlılığa dönüşür; bunun resmi bir vaat olup olmaması fark etmez. Birileri API'yi scrape eder, köşe vakaları otomatikleştirir, hataları cache'ler
- Bu da kariyer düzeyinde bir içgörü doğurur: uyumluluk işini "bakım", yeni özellikleri ise "gerçek iş" gibi göremezsiniz; çünkü uyumluluk ürünün kendisidir
- Bir kullanımdan kaldırmayı, zaman, araçlar ve empatiyle bir geçiş süreci olarak tasarlamak gerekir
- Çoğu "API tasarımı" aslında "API emekliliği" demektir
9. "Yavaş" ekiplerin çoğu aslında hizalanmamış ekiplerdir
- Bir proje geciktiğinde içgüdüsel tepki uygulamayı suçlamaktır: insanlar yeterince çalışmıyor, teknoloji yanlış, yeterince mühendis yok. Ama çoğu zaman asıl sorun bu değildir
- Büyük şirketlerde ekipler eşzamanlılığın birimidir; fakat ekip sayısı arttıkça koordinasyon maliyeti geometrik olarak yükselir
- Yavaşlığın çoğu aslında hizalanma başarısızlığıdır: yanlış şeyi inşa etmek ya da doğru şeyi birbiriyle uyumsuz şekilde inşa etmek
- Kıdemli mühendisler, "daha hızlı kod yazmaktan" çok yönü, arayüzleri ve öncelikleri netleştirmeye zaman harcar; çünkü gerçek darboğaz oradadır
10. Kontrol edebildiklerine odaklan, edemediklerini görmezden gel
- Büyük şirketlerde sayısız değişken kontrolünüz dışındadır: organizasyon değişiklikleri, yönetim kararları, pazar kaymaları, ürün dönüşleri. Bunlara saplanmak eylem gücü olmayan bir kaygı üretir
- Akıl sağlığını koruyan ve etkili kalan mühendisler, etki alanlarına odaklanır: yeniden yapılanma olup olmayacağını kontrol edemezsiniz ama işinizin kalitesini, nasıl tepki vereceğinizi ve ne öğreneceğinizi kontrol edebilirsiniz
- Belirsizlikle karşılaşınca problemi parçalara ayırıp kendiniz için mümkün olan somut adımları belirlemek gerekir
- Bu pasif kabulleniş değil, stratejik odaktır; değiştiremeyeceğiniz şeye harcanan enerji, değiştirebileceğiniz şeyden çalınmış enerjidir
11. Soyutlama karmaşıklığı ortadan kaldırmaz, sadece nöbet sizdeyken başka yere taşır
- Her soyutlama, altında ne olduğunu anlamanız gerekmeyeceği üzerine yapılmış bir bahistir ve bazen bu bahis kazanır
- Ama bir şeyler her zaman sızar; sızdığında da neyin üzerinde durduğunuzu bilmeniz gerekir
- Kıdemli mühendisler, yığın büyüdükçe "alt seviye" şeyleri öğrenmeye devam eder; nostalji yüzünden değil, soyutlamaların çöktüğü ve sabah 3'te sistemle baş başa kaldığınız anlara duyulan saygı yüzünden
- Stack'i kullanın, ama temel arıza modellerine dair işleyen bir zihinsel modele de sahip olun
12. Yazmak netlik dayatır. Bir şeyi daha iyi öğrenmenin en hızlı yolu onu öğretmeye çalışmaktır
- Yazmak netlik dayatır; bir kavramı başkasına açıklarken — ister dokümantasyon, ister sunum, ister code review yorumu, hatta yapay zekayla sohbet olsun — kendi anlayışınızdaki boşlukları fark edersiniz
- Bir şeyi başkası için okunabilir kılma eylemi, onu kendiniz için de daha okunabilir hale getirir
- Bu, cerrah olmayı öğretmek için öğretin anlamına gelmez; ama bu varsayım yazılım mühendisliği alanında büyük ölçüde doğrudur
- Bu sadece bilgiyi paylaşmanın cömertliği değil, aynı zamanda bencil bir öğrenme hack'idir: bir şeyi anladığınızı düşünüyorsanız onu basitçe açıklamayı deneyin; takıldığınız yer, anlayışınızın sığ olduğu yerdir
- Öğretmek, kendi zihinsel modelinizi debug etmektir
13. Başkalarının işini mümkün kılan işler değerlidir ama görünmezdir
- Glue work — dokümantasyon, onboarding, ekipler arası koordinasyon, süreç iyileştirme — zorunludur; ancak bilinçsizce üstlenildiğinde teknik yönünüzü duraklatabilir ve tükenmişliğe yol açabilir
- Tuzak, bunu sadece "yardımseverlik" olarak yapmak; kasıtlı, sınırları olan ve görünür etkisi bulunan bir iş olarak ele almamaktır
- Zaman sınırı koymak, rotasyona sokmak ve çıktıya dönüştürmek gerekir: dokümanlar, şablonlar, otomasyon. Ve bunu kişilik özelliği olarak değil, etki olarak okunabilir hale getirmek gerekir
- Değerli ama görünmez olmak, kariyer açısından tehlikeli bir kombinasyondur
14. Her tartışmayı kazanıyorsanız, muhtemelen sessiz direnç biriktiriyorsunuzdur
- Kendi kesinliğimden şüphe etmeyi öğrendim; çok kolay "kazandığınızda" genelde bir şeyler ters gidiyordur
- İnsanlar sizinle tartışmayı bıraktığında bunun nedeni onları ikna etmiş olmanız değil, vazgeçmiş olmalarıdır; bu uyumsuzluğu toplantıda değil uygulamada gösterirler
- Gerçek hizalanma daha uzun sürer: diğer bakış açılarını gerçekten anlamanız, geri bildirimi içeri almanız ve bazen herkesin önünde fikrinizi değiştirmeniz gerekir
- Haklı olmanın kısa vadeli hissi, isteyerek işbirliği yapan iş arkadaşlarıyla birlikte bir şey inşa etmenin uzun vadeli gerçekliğinden çok daha az değerlidir
15. Ölçüm hedefe dönüştüğünde, artık ölçüm olmaktan çıkar
- Yönetime sunduğunuz her metrik eninde sonunda oyunlaştırılır; kötü niyet yüzünden değil, insanlar ölçülen şeyi optimize ettiği için
- Kod satırlarını izlerseniz daha çok satır, hızı izlerseniz şişirilmiş tahminler elde edersiniz
- Kıdemli hareket şudur: her metrik talebine çift olarak yanıt vermek — biri hız için, biri kalite ya da risk için — ve sonra eşik tapınması yerine trend yorumlamasında ısrar etmek
- Amaç gözetim değil içgörüdür
16. Bilmediğini kabul etmek, biliyormuş gibi yapmaktan daha fazla güven yaratır
- "Bilmiyorum" diyen kıdemli mühendis, zayıflık göstermiyor; izin alanı açıyordur
- Lider belirsizliği kabul ettiğinde, başkalarına da aynısını yapabileceklerinin sinyalini verir; alternatif ise herkesin anlıyormuş gibi yaptığı ve sorunların patlayana kadar saklandığı bir kültürdür
- En kıdemli kişinin kafa karışıklığını kabul etmediği ekipler ve bunun verdiği zarar görülebilir: sorular gelmez, varsayımlar sorgulanmaz, genç mühendisler de herkesin anladığını varsayarak sessiz kalır
- Merakı modellediğinizde gerçekten öğrenen bir ekip elde edersiniz
17. Ağınız, sahip olacağınız tüm işlerden daha uzun ömürlüdür
- Kariyerin başlarında işe odaklanıp networking'i ihmal ettim; geriye dönüp bakınca bu bir hataydı
- Şirket içinde ve dışında ilişkilere yatırım yapan iş arkadaşları on yıllar boyunca bunun karşılığını aldı
- Fırsatları ilk onlar duydu, köprüleri daha hızlı kurabildi, roller için tavsiye edildi ve yıllar içinde güven inşa ettikleri insanlarla girişimler kurdu
- İşler kalıcı değildir ama ağınız her işinizden daha uzun yaşar; buna işlemsel bir koşuşturma gibi değil, merak ve cömertlikle yaklaşmak gerekir
- Ayrılma zamanı geldiğinde, çoğu zaman kapıları açan şey ilişkiler olur
18. Performans iyileşmelerinin çoğu, daha zeki şeyler eklemekten değil işi kaldırmaktan gelir
- Bir sistem yavaşladığında içgüdü ekleme yönündedir: cache katmanı, paralelleştirme, daha akıllı algoritmalar. Bazen bu doğrudur ama çoğu zaman daha büyük performans kazanımı, "hesaplamamıza gerek olmayan ne var?" diye sormaktan gelir
- Gereksiz işi silmek, neredeyse her zaman gerekli işi hızlandırmaktan daha etkilidir; en hızlı kod çalışmayan koddur
- Optimizasyondan önce, o işin gerçekten var olması gerekip gerekmediğini sorgulamak gerekir
19. Süreç, evrak izi üretmek için değil belirsizliği azaltmak için vardır
- En iyi süreçler koordinasyonu kolaylaştırır ve başarısızlığı daha ucuz hale getirir; en kötü süreçler ise bürokratik tiyatrodur — yardımcı olmak için değil, bir şeyler ters gittiğinde suçu dağıtmak için vardır
- Bir sürecin riski nasıl azalttığını ya da netliği nasıl artırdığını açıklayamıyorsanız, muhtemelen sadece ek yüktür
- İnsanlar işi yapmaktan çok işi dokümante etmeye zaman harcıyorsa, ciddi biçimde yanlış giden bir şey vardır
20. Eninde sonunda zaman, paradan daha değerli hale gelir; buna göre davranın
- Kariyerin başlarında zamanınızı para ile değiş tokuş edersiniz ve bu sorun değildir; ama bir noktada hesap tersine döner ve zamanın yenilenemeyen bir kaynak olduğunu fark etmeye başlarsınız
- Sonraki terfi seviyesinin peşinden koşup, ücret paketinin birkaç puanını daha optimize etmeye çalışırken tükenen kıdemli mühendisler görülür
- Bazıları bunu elde etti, ama çoğu sonradan vazgeçtikleri şeyin buna değip değmediğini sorguladı
- Cevap "çok çalışma" değil; "neyi neyle takas ettiğini bil ve bunu bilinçli yap" demektir
21. Kısayol yoktur ama bileşik getiri vardır
- Uzmanlık kasıtlı pratikten gelir: mevcut becerinizin biraz ötesine itmek, düşünmek, tekrarlamak — yıllar boyunca — bunun sıkıştırılmış bir sürümü yoktur
- Umut veren taraf şu: öğrenme, sadece yeni küçük bilgiler değil, yeni seçenekler ürettiğinde bileşik etki yaratır
- Yazın; etkileşim için değil, netlik için yazın; yeniden kullanılabilir ilkel parçalar oluşturun ve yara dokusunu çalışma rehberlerine dönüştürün
- Kariyerine bileşik faiz gibi yaklaşan mühendisler, ona piyango bileti gibi yaklaşanlardan çok daha ileri gitme eğilimindedir
Son düşünceler
- 21 ders çok gibi görünebilir ama aslında birkaç temel fikre indirgenir: meraklı kalmak, alçakgönüllü kalmak ve işin her zaman insanlarla ilgili olduğunu unutmamak — hem inşa ettiğiniz kullanıcılarla hem de birlikte inşa ettiğiniz ekip arkadaşlarınızla
- Mühendislik kariyeri, birçok hata yapıp yine de ilerleyebilecek kadar uzundur; en çok saygı duyulan mühendisler de her şeyi doğru yapanlar değil, yanlışlardan öğrenen, bulduklarını paylaşan ve gelmeye devam edenlerdir
- Yolculuğun başındaysanız bunun zamanla daha da zenginleştiğini bilin; derinlerindeyseniz de bunların bir kısmının size tanıdık gelmesini umuyorum
5 yorum
Hacker News görüşleri
“Ölçek büyüdükçe bug’ların da kullanıcıları olur” sözü aklıma geldi
İlk işimde yükleme süresini 5 dakikadan 30 saniyeye indirdiğimizde müşterilerin şikayet ettiği bir anı vardı
Çünkü eskiden bilgisayarı açıp kahve içerken sohbet ettikleri zaman ortadan kalkmıştı
Bu hikayenin dersi sadece geliştirme yapmamak değil, yazılımın gerçek insanların alışkanlıkları ve etkileşimleri içinde var olduğunu unutmamak
Mühendisin işi ticket kapatmak değil, gerçek kullanıcı problemlerini çözmektir
Verimlilik arttıkça çalışanların daha fazla fiziksel emek harcaması gerekti ve bu da memnuniyetsizlik yarattı
Sonunda ben, ‘iyi bir sistemi bozan kişi’ gibi göründüm
“Yeterince çok kullanıcınız varsa, sistemin gözlemlenebilen her davranışı birilerinin bağımlı olduğu bir şeye dönüşür” diye bir söz vardır
Her seferinde “bu kez düzeltirler” diye düşündüm ama 10 yıl boyunca düzeltilmedi ve işin sürmesini sağlayan da bu oldu
Bu üç taraf problemi birbirinden farklı şekilde anlar
Kodun anlamı niyet ya da temenniyle değişmez; yalnızca gerçek dünyanın kısıtları içinde çalışır
İlgili yazı: Laws of Software Evolution
Ama her şirket böyle düşünmüyor
Mülakatta beklentileri net biçimde anlamak önemli
Addy Osmani’nin yazısını görünce biraz ikiyüzlülük hissettim
Eskiden kodumu intihal etmişti; sonradan özür yazısı yayımladı ama bunu sosyal medyada paylaşmadı
Samimi bir özürse, takipçilerine de açıkça duyurması gerektiğini düşünüyorum
İlk üç ders özellikle çok anlamlı geldi
Sorun, eğitim sürecinde problemin kendisini değil yalnızca dilleri ve framework’leri öğrenmemiz
Uzlaşma yaratıcı süreç içinde birikir, güç ise kriz zamanında kullanılmalıdır
Başarısızlıktan korkup sadece tartışarak zaman kaybettiğimiz çok olur
‘İnovasyon tokenı’ kavramını ilk kez “Boring Technology” makalesinde öğrenmiştim
boringtechnology.club yazısı; hâlâ en sevdiğim mimari yazılarından biri
“Soyutlama karmaşıklığı ortadan kaldırmaz, sadece sen on-call olduğunda karşına çıkarır” sözü bana Joel Spolsky’nin Law of Leaky Abstractions yazısını hatırlatıyor
15 yıllık liderlik kariyerim boyunca büyük bir perakende şirketinde milyarlarca dolarlık sistemler işlettim
Ama sonunda asıl önemli olanın politika ve insan ilişkileri olduğunu gördüm
Daha zeki insanlar da politikayı beceremediği için terfi alamadı
Çocuklara “politikayı ve göze girmeyi öğrenin” demek zorunda kalmak acı bir sonuç
“Clarity is seniority” sözüne çok derinden katılıyorum
Açıklık, bakım yapılabilirliğin ve ölçeklenebilirliğin temelidir
Ben de bunu anlatan Elements of Code kitabını yazdım
Sorun soyutlamanın kendisi değil, amacın açıklığıdır
Bu, araziye bakmadan deponun içinde köprü kuran bir inşaat mühendisi gibi
Suçu soyutlamaya atmak yerine, neyi modellemeye çalıştığını anlamak gerekir
Yanlış soyutlama açıklığı bozar ve gereksiz karmaşıklık üretir
Gerekirse yetersiz soyutlamayı tercih ederim
Bu tür listelerin asıl değeri onu bizzat yazmaya çalışmakta
Sadece okumakla hızla unutuluyor; kendi kariyerine dönüp bunları düzenleyince anlam kazanıyor
Bu yazı Google’ın resmî değerlerini değil, Google’da çalışırken öğrenilmiş kişisel dersleri anlatıyor
Kurumun öğrettikleri değil, deneyimlerin içinden kişinin kendisinin çıkardığı sonuçlar
Esas nokta, büyük şirketlerde bile bunların hâlâ zor konular olması
“Ölçek büyüdükçe bug’ların da kullanıcıları olur” sözü ossification (katılaşma) olgusuna benziyor
Bu sadece ağ protokolleri için değil, tüm sistemler için geçerli
HTTP/3 ve QUIC’in şifreleme tasarımının nedeni de ara cihazların yanlış varsayımlar yapmasını engellemek
API’lerde de aynı şekilde iç durumu açığa vurmamak gerekir
“Bias towards action” cümlesi etkileyiciydi
Ne kadar iyi tavsiye olursa olsun, boş bir sayfaya faydası olmaz
Geri bildirim alabilmek için önce bir şey üretmek gerekir
İlk harfi yazdığın anda, beklenmedik problemler görünür hâle gelir
Organizasyon ne kadar büyükse bu tür görünmez darboğazlar da o kadar fazladır
“Ship fast”, “özensizce yayımla” demek değildir
Daha derli toplu bir minimum uygulanabilir ürünün daha iyi olduğunu düşünüyorum
Gerçek ile ideal arasındaki fark büyük; yazar bunu “Kool Aid lezzetliydi” diyerek hicvediyor
Aksi hâlde bu “savsaklama” diye anlaşılır ve bir sorun çıktığında günah keçisi olursun
Güzel bir yazı olmuş. Kariyer gelişiminin kişisel olgunlaşmayı da içerdiği fikrini yeniden hatırlamak için bir fırsattı. Keyifle okudum.
Söylenenlerin hepsi tek tek son derece doğru.
Bu aralar bunu iliklerime kadar hissediyorum haha
Harika içerik o kadar fazlaydı ve içgörü barındıran cümleler o kadar çoktu ki hayranlığımı gizleyemedim. Ana cümlelerin kalın yazıyla belirtilmiş olması da ayrıca hoşuma gitti.
"Haklı olmak gibi kısa vadeli bir his, gönüllü iş birliği yapan çalışma arkadaşlarıyla birlikte bir şeyler inşa etmenin uzun vadeli gerçekliğinden çok daha az değerlidir."
"Stratejik odaklanma gerekir; değiştiremeyeceğin şeylere harcadığın enerji, değiştirebileceğin şeylerden çalınmış enerjidir."
Sadece işte değil, hayata uygulamak için de çok uygun pek çok nokta vardı. Güzel yazı için teşekkürler.
"Kod, bir kesinti sırasında sabahın 2'sinde bakım yapacak yabancılar için yazılmış stratejik bir nottur; bu yüzden anlaşılırlığı en üst düzeye çıkarabilmelidir."
"İlerleme netlik yaratır ve analiz felci hiçbir şey üretemez."