Üretkenlik Serabı

 (frantic.im)
1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Facebook’un efsanevi mühendisi Bob, karmaşık bir geliştirme ortamı olmadan da Facebook Groups’u yayına aldı ve hackathonlarda art arda başarı elde etti
  • Yalnızca temel Sublime Text ve printf logları kullandı; sözdizimi vurgulaması hatalıydı ve ne live reloading ne de debugger vardı
  • Buna karşılık çevresindeki geliştiriciler, Vim sözdizimi vurgulaması ve snippet’ler, tmux, mosh, hphpd kısayolları, Git alias’ları gibi karmaşık araç düzenlerini üretkenliğin anahtarı olarak görüyordu
  • Ancak Bob’un hackathon zaferlerinde editör ayarlarından çok ürün sezgisi ve içgörüsü, yani ne yapılacağına karar verme becerisi etkili oldu
  • Yeni çalışma biçimleri değişim yaratabilir, ama nihai sonuçlar eninde sonunda doğru problemi çözmekten gelir

Karmaşık araçlarla gerçek sonuçlar arasındaki fark

  • Bob, Facebook Groups’u yayına alan üretken bir mühendis ve hackathonlarda art arda ürün çıkaran efsanevi bir isimdi
  • O dönemde üretkenliğe kafayı takmış bir çalışma arkadaşı, Facebook’un PHP lehçesi Hack için kendi yaptığı Vim sözdizimi vurgulaması ve snippet’ler kullanıyordu
    • mosh üzerinde tmux çalıştırıyor, özel hphpd kısayolları ve Git alias’ları bile ayarlıyordu
  • Bob’un çalışma tarzı ise buna kıyasla son derece basitti
    • Ek ayar yapılmamış Sublime Text kullanıyordu; kod renklerinin yaklaşık yarısı yanlış gösteriliyordu
    • Live reloading ya da debugger yerine koda printf ekliyor ve logun gelmesini bekliyordu
  • O günkü hackathonda Bob kazandı; yaptığı şeyin, Facebook Groups’ta alım-satım gönderilerini destekleyen bir özellik olduğu hatırlanıyor
    • Bu özellik daha sonra Facebook Marketplace’e dönüştü

Nasıl’dan çok ne yapılacağı

  • Karmaşık araçlara odaklanmak, işin nasıl yapıldığına saplanıp işin ne olduğunun gözden kaçmasına yol açabilir
  • Bob’un yüksek üretkenliğinin asıl kaynağı editör ayarları değil, ürün sezgisi ve içgörüsüydü
  • X’te her gün her şeyi değiştirecekmiş gibi görünen yeni çalışma biçimleri ortaya çıkıyor; bunların bir kısmı gerçekten fark yaratabilir
  • Ancak en önemli şey araçların ya da çalışma biçimlerinin kendisi değil, doğru problemi çözmektir

İlgili okumalar

1 yorum

 
GN⁺ 1 시간 전
Hacker News yorumları

  • Aletini esirgemeyen zanaatkâr ile aletlere takıntılı kişiyi ikiye ayırmak yanlış. İyi araçlar oyuncak değil, amaca giden birer araçtır; ben de iş akışıma uygun shell script’leri, Emacs fonksiyonları, pencere düzenleme araçları vb. yapmak için günler harcadım.
    Sonuçta sözdizimi vurgulama, kodda gezinme ve analiz, ekran düzeni, Git işlemleri birkaç tuş vuruşuyla yapılır hale geldi ve odağı bozan unsurlar ortadan kalktı. Sandalye, shell prompt’u, editör gibi çalışma ortamına yatırım yapın; rahat ettikten sonra bunları unutup asıl probleme odaklanın.
    Ancak bitmek bilmeyen araç ayarları, yorucu ve eğlenceli olmayan görevlerden kaçınmanın işareti olabilir; bu da araçların kendi hatasıymış gibi basit bir mesele değildir.

    • Yeni bir işte yeni bir teknoloji yığını ve Windows dizüstü bilgisayar verilirse ne yapacaksınız? Kariyerimin başlarında bana verilen ortamın varsayılan araçlarıyla verimli çalışmayı öğrendim; gerçekte araçları doğrudan seçebildiğiniz durumlar nadirdi. Platformlar arası araçlar da JetBrains ürün ailesi dışında pek tutarlı değil.
    • Bu, samuray ile ninja arasındaki farka benziyor. Samuray kılıcı ruhunun uzantısı olarak görürdü; ninja ise gerekirse kılıçla bir şeyi kanırtıp açardı. Bugünün ekonomisinde samuray tarzı araç anlayışı uygun değil.
    • Araçları keyifle kullanmak önemli. Verimliliği 10 kat artırmasa bile mesele işe odaklanmak ve süreçten keyif almak.
      Özellikle LLM çağındaki araçlar insanı sürekli birden fazla ajan ve terminal arasında gidip gelmeye zorluyor. Bu sık bağlam değişimi keyfi ve akış hâlini elimizden alıyor; umarım biri buna çözüm bulur.
    • Acemilerin kabul görmek ve ciddiye alınmak istedikleri için gerekli adımları çoğu zaman atladıkları görülüyor. Öyle görünmek ile gerçekten öyle olmak farklı şeyler; ayrıca beceri geliştirirken geçimi de sağlamak gerekiyor.
    • Bir teknolojide ustalaştıktan sonra iyi araçların kendisi büyük bir keyif haline geliyor. Tersine, deneyimli kişiler bazen uygun olmayan araçlarla bile şaşırtıcı derecede iyi sonuçlar çıkarabiliyor.

  • Birçok teknisyenin gerçekten bir şey üretmekten çok ortam ayarlarını optimize etmeye daha fazla zaman harcadığını gördüm; ben de bunu yaptım. Kodlama süresinin %90’ı yazı yazmak olduğuna göre giriş hızını artırmak gerekir düşüncesi yanlış; zamanın %90’ı düşünmeye, bunun da çoğu okumaya harcanmalı.

    • Yazılım, bir probleme yönelik çözümün somutlaşmış hâlidir; bu yüzden önce çözülecek problemi tanımlamak gerekir. Kod, mevcut problem anlayışınızı ve çözümün açıklığını/uygunluğunu, gelecekteki siz dahil herkese gösteren bir anlık görüntüdür.
      Doğru andaki kodlama, zaten anlaşılan çözümü somutlaştıran bir yazma işine yakındır.
    • Eskiden ayarlara takıntılıydım; yapay zekâ kullanmaya başladıktan sonra ise önceden yapamayacağım harika şeyler yapıyorum. Buna karşılık temel kodu anlama düzeyim ve mevcut becerilerim yavaş yavaş zayıflıyor; yeni tekniklere hayran kalıyor ama derinlemesine öğrenemiyor gibiyim.
      Yapay zekâ, başlangıçta aşılması gereken eşiği düşürdüğü için bir başka ortam iyileştirme biçimi sayılabilir. Eskiden QA rolünden geliştiriciliğe geçmeye çalışırken Avrupa’yı dolaşıp InterviewCake çalıştığım dönemde de problem çözmek yerine editör ayarlarını ince ayarlamakla zaman harcamıştım.
      Bu, ADHD belirtisi de olabilir. Yakın zamanda ilaç tedavisine başladıktan sonra üretkenliğim ciddi biçimde değişti; gerçek işi yapmak yerine ayarları mükemmelleştirmeye hayatımın yarısını harcadığımı düşününce ağlayacak gibi oldum.
    • Gerçek üretkenlik ile hissedilen üretkenlik arasında bir kopukluk var. Vim ya da Emacs ile kod üzerinde ustaca tuşlara basınca kendinizi hacker gibi hissedersiniz, ama bu üretken olduğunuz anlamına gelmez. Devasa token’larla onlarca yapay zekâ ajanını yönetseniz bile çıktının çalışacağı ya da problemi çözeceği garanti değildir.
    • Sıradan CRUD uygulaması geliştiricilerinin çoğu için zamanın %90’ını düşünmeye ve okumaya harcamak gerektiği oranının doğru olup olmadığından emin değilim.
    • Düşünme ve yazma çoğu zaman aynı anda gerçekleşir. Birçok kişi kod yazıp değiştirirken problem üzerine daha kolay akıl yürütür; LLM’in ürettiği kodun tamamını okusanız bile kod anlama düzeyinin ciddi biçimde düşebilmesinin nedeni de budur.

  • Gerçekten kullanılan ya da para ödenen ürünler yapamayan VC destekli şirketler var. Bunlar şirket değerlemelerini haklı çıkarmak için ne kadar meşgul ve üretken olduklarını gösteriyor; yapay zekâ furyası da ne yapılacağından çok üretkenlik ve yöntemlere odaklandığı için aynı bağlamda görülebilir.
    https://components.news/the-gamer-and-the-nihilist/ bu tür nihilist startup’ları insanların para ödeyip kullandığı ürünler yapan oyun geliştirme şirketleriyle karşılaştırıyor. Üretkenlik uygulamalarının Product Hunt çıktılarının neredeyse %40’ını oluşturduğu bir ekonomide emek, gerçekten bir şey yapmak yerine yapıyormuş gibi görünmeye de harcanabiliyor.

    • Oyun geliştiricileri de araç yapımına muazzam çaba harcar; sadece ana hedef metin editörleri değildir.
    • Oyundan çok mükemmel oyun ortamını kurmaya sayısız saat harcayan insanlar ya da müzikten çok kusursuz ekipmanı hayatı boyunca arayan audiofiller bu benzetmede nereye düşüyor, merak ediyorum.
    • Balondan ziyade, uzun zamandır tekrarlanan sinyal manipülasyonuna daha yakın. Hep vardı ve olmaya devam edecek.

  • Üretkenlik araçlarını sadece geri kalmayacak kadar yapar ya da kullanırım; fazlasını tuzak olarak görürüm. Eskiden çeyrekte bir kez gözden geçirirdim, ama yapay zekâdan sonra haftada 1-2 günü araç iyileştirme denen meta işe harcıyorum; ilgili araçlar standartlaştıkça bunun azalacağını düşünüyorum.
    Araç uzmanı imajı güçlenirse, gerçekten değerli işleri kaçırmakla kalmaz, gizli üretkenlik sırlarına sahip biri olarak da değerlendirilirsiniz. Beklendiği kadar fark yaratmazsanız diğer yargılarınıza duyulan güven de sarsılabilir.

  • Bilgisayar başında geçirdiğim zaman azaldıkça daha çok iş bitirdim; monitörleri 3’ten 1’e indirince üretkenliğim ciddi biçimde arttı. Sebze doğrarken ya da çim biçerken problemlerin çoğunu çözüyorum; parlak teknolojinin karşısında oturmak daha hızlı ve daha iyi kararlar getirmiyor.
    Müşteri şirketlerin geliştirme ekiplerinden daha iyi sonuç almamın nedeni de tam zamanlı çalışan olmamam; yeterince durup yavaşça düşünebilmem. Teams durum göstergesini yeşil tutma baskısı gibi üretkenlik tiyatrosu, birçok organizasyonda aptalca kararlar üretiyor.

    • 15 yıl boyunca Kaliforniya La Jolla’da denize bakan bir uçurumda ofisleri olan iki şirkette çalıştım. Uçurum ve parkta yürürken iş üzerine düşünürdüm; beyaz tahta gerektirmeyen ciddi bir tartışmaysa meslektaşıma birlikte yürümeyi önerirdim. Rich Hickey’nin hammock talk’unu tekrar dinlemeye değer.
    • Kullanıcı adına bakınca yazıda geçen Bob olup olmadığını merak ettim.

  • Üretkenliğin neden var olduğunu düşününce bunun acıyı azaltma girişimi olduğu varsayımına vardım. Programcı üretkenliği dahil pek çok performans optimizasyonu, problem alanının belirsizliği, kurum içi politika, muğlaklık ve başarısızlık riski gibi acılardan kaçmak isteyen mühendisler için bir sığınak hâline gelebiliyor.
    Ama gerçek dünyadaki sorunları çözmek için kullanıcı iş akışlarını sıkıcı derecede ayrıntılı incelemek, ortak stratejiyi açıkça önerip başkalarının iş birliğini kazanmak gibi yollarla gerçekle yüzleşmek gerekir. Acının kendisini yüceltmeye gerek yok; ancak iyi sonuçların içinde sporcu benzeri bir antrenman vardır ve sahada gereken acıyı yönetme becerisini geliştirmek gerekir.

  • Mesele, takdir edilmenin kolay olup olmadığı. Parlak araçları herkes görüp hayran kalabilir; ama boş bir editörde ya da iskelet kodda harika yeni bir ürün veya özelliği fark eden azdır. Bu yüzden görünür araçlara ilgi yığılır; zor ve belirsiz olan “ne yapılacak” sorusu göz ardı edilir.
    Araçlara Marie Kondo tarzı bir ölçüt uygularım. Kullanması keyifli değilse ve hayatı kolaylaştırmıyorsa atarım; öyleyse tutarım.

  • 2004’te, çoğu junior geliştiriciden oluşan küçük bir ekip olarak mükemmel ve kapsamlı bir Java eğitimi alma fırsatımız oldu. Eğitimden önce IntelliJ ve Eclipse ayarlarına takılıp hararetle tartışmıştık; eğitmen ise şaşırtıcı biçimde yalnızca varsayılan JDK araçları ve Notepad kullanmamızı önerdi.
    Amaç, içeride neler olduğunu öğrenmemizi sağlamaktı; üretkenlikte de muhtemelen büyük bir fark olmayacağını söyledi.

  • Ortam optimizasyonuna takıntılı olmamızın nedeni, odaklanmış çaba ile ödül arasındaki bağın görünür, somut ve fiziksel olmasıdır. Buna karşılık soyut öğrenme böyle değildir. Optimize edilecek sandalyelerden çok daha fazla öğrenme görevi var; keşke soyut öğrenmeyi de daha somut hissettirecek bir yol olsa.

  • Bu üretkenlik değil, oyuncaklarla oynamanın keyfi meselesi.