İyi araçlar görünmezdir
(gingerbill.org)- İyi araç, kullanıcı işine odaklanmışken arka planda kaybolan araçtır; araç üreticisinin hedefi de aracın kendisini fark ettirmemek olmalıdır
- Bir aracın kusurlarını “eğlenceli bir bulmaca” diye paketlemek, zekice hissetmeyi gerçek üretkenlikle karıştırmayı kolaylaştırır
- vim, emacs, Sublime gibi editör seçimleri kişisel iş akışına uyabilir; ancak kusurları bile kimlik sinyali gibi savunmak, artıları ve eksileri dürüstçe görmeyi zorlaştırır
- TUI ve GUI tartışmalarında da mevcut uygulamaların eksiklerini kategorinin doğasından gelen sınırlarmış gibi görmemek gerekir; pek çok sorun iyi bir uygulama olmadığı için ortaya çıkar
- İyi varsayılanlar, kullanıcının zamanını koruyan tasarımdır; yüksek yapılandırılabilirlik veya dik öğrenme eğrisi ancak gerçek üretkenlikle karşılığını veriyorsa katlanmaya değerdir
İyi bir aracın ölçütü
- İyi araç görünmez olmalıdır
- Kullanıcı aracın kendisini düşünmeden işine devam edebildiğinde araç arka planda kaybolur
- Araç belirli bir işte kullanıcıyı tökezlettiği anda kullanıcı tekrar aracın farkına varır
- Eksikleri “eğlenceli bir bulmaca” olarak yeniden paketleyen tutum, araç değerlendirmesini bulanıklaştırır
- Dolambaçlı bir çözüm bulmanın keyfi, aracın kalitesini kanıtlamaz
- Kusurlardan hobi gibi keyif almak ile aracın gerçekten iyi olması ayrı konulardır
Metin editörü tartışması
- vim yalnızca bir örnektir; aynı mantık emacs veya Sublime gibi başka editörler için de geçerlidir
- Bazı kullanıcılar vim’in güçlü yanlarından çok, zayıf yanlarını çözme sürecini eğlenceli bir bulmaca gibi över
- Tek seferlik bir metin refaktörleme işi için makro yazmanın eğlenceli olduğuna dair örnekler vardır
- Aynı iş Sublime’ın çoklu imleçleriyle bir dakikadan kısa sürede yapılabiliyor ya da basit bir betikle çözülebiliyorsa, makro işi gerçek üretkenlik ölçütünde zayıf kalır
- Editörler iş akışı için önemlidir; ancak belirli bir editörü “hacker havası” yüzünden neredeyse dinsel biçimde takip etmek tehlikelidir
- vim veya emacs ile yeni tanışan biri için bu hava çekici gelebilir
- Alışkanlık kusurları örtebilir ve bu kusurları bir oyun gibi övünç konusu hâline getirebilir
Sublime kullanma nedenleri ve kabul edilen sınırlar
- Sublime, 15 yıldır kullanılan editördür ve seçilme nedenleri birkaç maddede özetlenebilir
- Kısayolları grafik OS ortamının bir üst kümesine yakın olduğu için uygulamalar arasında geçerken bilişsel geçiş maliyeti düşüktür
- Çoklu imleçlerin, vakaların %99,999’unda makrolardan daha iyi olduğu düşünülür
- Çoklu imleçler doğrudan görsel geri bildirim sağlar
- Metin düzenleme iş akışında çözülmesi gereken “bulmaca” en azdır
- Sublime’da da kusurlar vardır
- Gerekli bir araç olmadığı için eklenti kullanmak ya da metin dönüşümünü ayrı bir programla yapmak gereken durumlar olur
- Bu kusurlar “eğlenceli bir bulmaca” diye paketlenmez; sadece rahatsızlık olarak kabul edilir
- vim, temel düzenleme için daha iyi olabilir; ancak grep tarzı işler dışındaki toplu işlemlerde daha zayıf görülür
- vim motion’larının Sublime iş akışından çok daha üretken olduğu hissedilmez
- Kod neredeyse hiç terminalde yazılmadığı için terminal odaklı bir editöre fiilen ihtiyaç yoktur
Araç kimliğe dönüştüğünde
- Araç seçimi, kişinin nasıl biri olduğunu gösteren bir bayrak gibi işleyebilir
- “Hacker havası” basit bir estetiğin ötesine geçip kabile sinyali de olabilir
- Kimlik araca bağlandığında, kusurları kabul etmek insanın kendisini inkâr etmesi gibi hissettirir
- Bu yüzden kusurlara katlanmakla kalınmaz; onlar savunulur ve övülür
- Araç kişiliğinin bir parçası hâline gelmiş biriyle araçlar hakkında dürüst bir konuşma yapmak zordur
Üretken hissetmek ve gerçek üretkenlik
- Editör makrosu örneği, üretken hissetmek ile gerçek üretkenlik arasındaki farkı gösterir
- Zor bir problemi çözerken oluşan zeki olma hissi, gerçek çıktı ile kolayca karıştırılır
- Zor işleri kahramanca hissettiren ve zekiliği başarı gibi duyumsatan araç güçlü görünebilir
- Aynı anda gerçek çalışma hızı sessizce yavaş olabilir
- Dürüst ölçüt, akış hissi ya da zekilik değil, geçen süre ve hata sayısıdır
- Pek çok kişinin misyoner gibi önerdiği araç bu ölçütte geride kalabilir
- Amaç üretkenlikse, insan kendi inançlarından gerçekten şüphe etmeli ve neyin daha üretken olduğunu kontrol etmelidir
TUI ve GUI tartışması
- Bütün gün terminalde kalan kullanıcılar için terminal uygulamalarının avantajları açıktır
- Ancak çoğu programcı bütün gün terminale hapsolmuş değildir
- GUI uygulamalarının yalnızca klavyeyle gezilemediği eleştirisi, GUI’nin özünde kötü olduğu anlamına gelmez
- Pek çok GUI yalnızca klavye ile gezinmeyi yeterince desteklemez
- GUI’yi klavyeyle gezilebilir yapmakta doğası gereği imkânsız bir şey yoktur
- Pek çok araç üreticisi bunu uygulamaz ya da klavye ile gezinmenin sık sık fare kullanmaktan daha üretken olduğu çok sayıda durum bulunduğunu fark etmez
- Belirli bir TUI uygulamasının belirli bir GUI alternatifinden daha iyi olduğunu söylemek geçerli bir karşılaştırma olabilir
- Ancak TUI’nin GUI’den özünde daha iyi olduğu yargısı, mevcut uygulamaların sınırlarını doğal sınır sanma hatasına yakındır
Linux masaüstü ve ayar yapmanın keyfi
- 2026’da bile “Linux masaüstü yılı” gelmiş değildir
- Bunun nedenlerinden biri, Linux kullanıcılarının önemli bir kısmının yapılandırma dosyalarıyla oynayıp sistemi değiştirmeyi eğlenceli bir bulmaca olarak sevmesidir
- İnsan bizzat böyle bir dönemden geçmiş olsa bile, zamanla sadece düzgün çalışan araçlar istemeye başlar
- Saatlerce ya da günlerce ayar yapmak artık istenen bir şey değildir
- Varsayılanlar iyi olmalı ve hemen çalışmalıdır
- Küçük bir ayar gerektiğinde birkaç saniye içinde bitmelidir
- En yüksek düzeyde yapılandırılabilirlik aracın hedefi değil, gerçekten gerektiğinde kullanılan bir seçenek olmalıdır
- Ergonomik araç tasarımı, iyi varsayılanları ve gerektiğinde çıkış yollarını birlikte sunmaktır
İyi varsayılanlar ve araç üreticisinin sorumluluğu
- İyi varsayılanlar araç üreticisinin sorumluluğudur
- Araç üreticileri yapılandırma, ayarlama ve öğrenme yükünü kullanıcıya devretmeye yatkındır
- Bu yüklerin çoğu, tasarımcının karar vermekten kaçınmasının sonucudur
- “Yüksek yapılandırılabilirlik”, hiçbir görüş belirtmeden sorunu kullanıcıya devretmenin bahanesi olabilir
- İyi varsayılanlar, kullanıcının zamanına saygıdır
- Araç üreticisi bir kez düşünürse sayısız kullanıcının aynı düşünme sürecini tekrarlaması gerekmez
- Çıkış yolları, sıra dışı gereksinimleri olan gerçek bir azınlık için düzenektir
- Genel durumu düzgün yapmanın yerine geçmemelidir
Dik öğrenme eğrisi bir özellik değildir
- Bazı araçların zorluğunun esas olduğu yönünde bir savunma da vardır
- Kendini adamamış kişileri elediği ve eşik aşıldığında ömür boyu karşılığını verdiği mantığıdır
- Öğrenme eğrisi maliyettir, erdem değil
- Bu maliyet değerli olabilir; ancak ödülü gerçek üretkenlik olmalıdır
- Maliyeti ödemiş olmanın tatmini başlı başına ödül olmamalıdır
- “Aylarca öğrendim, öyleyse değerli olmalı ve başkaları da bunu izlemeli” mantığı, batık maliyeti yetenek gibi paketler
- Bu noktada bulmaca, araçla yapılan iş değil aracın kendisi olur
Araç seçiminden daha önemli olan tutum
- Bu, belirli bir araca karşı bir argüman değil; araçlara yaklaşma biçimine yönelik bir eleştiridir
- vim, emacs, Sublime; hangisi olursa olsun kullanılabilir
- Ölçüt, o aracın arka planda kaybolup kullanıcının işine devam etmesini sağlayıp sağlamadığıdır
- Bu ölçüt kişisel bir ölçüttür
- Sorun, araç seçiminin etrafına eklenen anlatılardır
- Sınırlar özellik olarak yeniden paketlenir
- Kusurları dolanma çabası ödül gibi satılır
- Araç “kullanılan bir şey” olmaktan çıkıp “kişinin bir parçası” statüsüne yükselir
- Bir aracın gerçekten hizmet ettiğinin en açık işareti, kullanıcının o aracı fark etmemeye başlamasıdır
- En iyi araç, en iyi hikâyeye sahip olan değil; kullanıcısına onu kullandığını unutturan araçtır
1 yorum
Hacker News görüşleri
Geliştirici ekipleri için epey fazla iç araç tasarlamış biri olarak buna gerçekten katılıyorum
Eskiden kullanıcılar geliştirici olduğu için “iç yapıyı” açık bırakmanın daha iyi olduğunu düşünürdüm; ama pratikte bu, ekip arkadaşlarımın asıl işlerini yapmasının önüne engel koymaktan başka bir işe yaramadı
Ekip arkadaşlarım benim yaptığım aracı, şirketin ihtiyaç duyduğu işi yapmak için kullanıyor; başka yerde asla karşılaşmayacakları küçük bir araçla oyalanmak istemiyorlar ve istemeleri için de bir neden yok
Hâlâ bolca kaçış yolu bırakıyorum, ama iç araçları kullanıcıların doğal biçimde başarı çukuruna düşeceği şekilde tasarlamaya çalışıyorum
Ayrıca hata mesajları, hata mesajları, hata mesajları ve yaygın hatalar için otomatik öneriler önemli
Yazının örneklerine takılıp yazının asıl niyetini görmeyen çok kişi olması da hayal kırıklığı yaratıyor
Kullanıcının önem verdiği işi doğrudan yapmasına yardımcı oluyorsa yapılandırılabilirlik çok değerlidir; ama daha az önem verdiği bir sorunu ortadan kaldıran bir araçsa aksine engel olabilir
Örneğin Gusto’nun maaş, vergi ve form gönderimlerini sizin yerinize halletme biçimi gerçekten iyi. Çünkü neredeyse düşünmeniz ya da dokunmanız gerekmiyor
Ama maaş bordrosu, muhasebe ve vergi asıl işi olan ya da büyük şirketlerin İK, hukuk veya finans departmanlarında çalışan biri için bu tür bir basitleştirme zararlı olabilir. Ya araçla boğuşmak zorunda kalır ya da daha az iyi bir ifadeyle, araç onun işini fazla basite indirger
Ayrıca parayı gerçekte kimin ödediği; aracın denetlenebilirlik, güvenlik, istenmeyen davranışları sınırlama gibi savunmacı amaçlar için mi yoksa yaratıcı amaçlar için mi kullanıldığı da büyük mesele. Yaratıcı özellikler daha çekicidir ama nicelleştirmesi zordur; son kullanıcı da kendi rolüne ne kadar yardımcı olursa olsun bunun için o kadar büyük para ödemek istemez
Mantıklı varsayılanlar koyup, gerekirse özelleştirmeye izin verme yaklaşımı. %80’lik kullanım senaryosundan başlanmalı; isterse değiştirebilmeli ve bu isteğe bağlı olmalı
Özellikle geliştirici araçlarında güçlü görüşler koymaktan çekinme eğilimi var. Bir seçeneğin “her zaman doğru” olduğundan emin değilseniz kullanıcıya sormak daha güvenli görünür; geliştiriciler de oldukça titizdir
“%95’i muhtemelen bu yolu isteyecek, ama %5’in de haklı noktaları var; o yüzden herkese eşit davranayım” derseniz, çoğunluk kullanıcı için daha kötü bir araç ortaya çıkar
Özelleştirmeyi desteklemek sanıldığından çok daha karmaşık. Mesele sadece bug’lar değil; her bir seçenek kullanıcı deneyimini cilalamayı zorlaştırır. Test kapsamı da büyür; daha esnek soyutlamaları tasarlamak da daha zordur
Yine de hâlâ denge kurulması gereken bir nokta var: insanları doğru yönteme zorlamak
Doğru yapmak uğruna takıldığını söyleyip yakınan biri her zaman vardır ve çoğu zaman bunu zaman kaybı olarak hissederler
Kurum açısından hedef, çalışanın şirkette kaldığı süre boyunca en yüksek performans eğrisini oluşturmasıdır; çalışan açısından ise tüm kariyeri boyunca bir performans eğrisi oluşturmasıdır
Bunun büyük kısmı ilgili kişilerin ilişkisine bağlı. Bir nakliyeci bir gün önce spor yapıp kas ağrısı çekiyorsa benim açımdan daha yavaş ve daha kötü sonuçtur; ama nakliye şirketi açısından uzun vadede güçlenip daha fazla iş yapabilecek olması iyi olabilir. Yine de o gün işi bırakır ya da kovulursa sonuç yine kötü olur
Asıl değerlendirme makrolar ile Sublime düzenleme arasında hangisinin daha iyi olduğu değil; makro oluşturma düşünce sürecinin başka işlerde işe yarayıp yaramadığı ve ondan önce ne yapıyor olduğudur
Kendi deneyimime göre, makro kullanmaya ya da Vim öğrenmeye harcadıkları zamanı gerçekten anlamlı işe ayıracak insan sayısı çok az. Genellikle sıkıldıkları ya da tükenmiş oldukları için, o anda eğlenceli gelen başka bir şeyi düşünmek istiyorlar
Sorun çalışanların rastgele script’ler yazması değil; mevcut işe dair aciliyet ya da ilgi eksikliği olması
Arayüzün “görünmez” hâle gelme etkisi aslında o arayüzün içinde geçirilen zamanın bir fonksiyonu
Yazarın tepki verdiği şey, tasarımcıların ya da ürün yöneticilerinin özellik veya karmaşıklık eklemesiyle oluşan isteğe bağlı sürtünmeye daha yakın görünüyor
Ama belirli bir işi başarmak için bu tür bir sürtünme gerekli olabilir. Merge conflict çözme durumunu düşünmek yeterli. Ayrıca yeterince uzun süre kullanınca o “rahatsız edici” adımlar bile arka plana kaybolur
Somut olarak 737 kokpiti kumandalarla inanılmaz derecede doludur. Uçağın kendisinin de birden çok modu vardır ve kasıtlı sürtünme de fazladır
Ama 737’yi 10 yıldan uzun süre kullanmış bir pilota sorarsanız, o arayüzün görünmez hâle geldiğini söyleyecektir
Genelde “kötü” sayılan Bloomberg Terminal de böyledir. Tıp alanında da günde 8 saatten fazla MR tarama yazılımı kullanan ve tüm kontrollere anında erişmek isteyen biri için düğmelerle dolu bir arayüz tam olarak doğru çözüm olabilir
Programcılar kendi deneyim ve tercihlerini fazla hızlı genelleyip başkalarına uygulama eğiliminde
Kaynak: IDEO’da 10 yıl tüketici ve profesyonel yazılım tasarladım
Yazı bunu kullanıcı tarafında ele alıyor ve çekirdek işlevden daha düşük nihai değere sahip “ek” özellikleri öğrenmekten hoşlanan bir kullanıcı türü olduğunu düşünüyor
“İnsanlar vim, emacs vb.’yi gerçekten iyi ve üretken buldukları için kullanıyorsa eleştirmem. İnsan alışık olduğu şeyde en rahat hisseder. Ama benim bahsettiğim kişiler, bu alışkanlık yüzünden aracın kusurlarını göremiyor ve o kusurları bir oyunmuş gibi sergileyip övmeye başlıyor” kısmı asıl nokta
Uzun süredir terminal kullanan biri olarak insanların bunu anlamamasına pek şaşırmıyorum. Konuşma genelde şöyle akar:
“Terminalde basit komutlarla şunları bunları yapabilirsin”
“Benim FrobnicatorStudio’mda bunun için Ctrl+Alt+So kısayolu var”
Bu böyle sonsuza kadar gider ve “Vim’de dört tuşa basarak 24 satır silebilirsin” ile “Sublime’da çoklu imleç var” gibi neredeyse anlamsız karşılaştırmalara dönüşür.
Muhtemelen asıl mesele, terminalin küçük komut satırı araçlarını pipeline’lar hâlinde birleştirme biçimi sayesinde sonsuz sayıda kullanım senaryosunu kapsaması, ama rahat etmeye başlayana kadar yaklaşık 1 yıllık bir öğrenme eğrisi gerektirmesidir.
O noktaya ulaştığınızda ortalama bir GUI kullanıcısından çok daha üretken olabilirsiniz; ancak oraya varmak adanmışlık ve acı gerektirir ve birçok kişi bunu isteyerek değil, mecbur kaldığı için yapar.
Benim durumumda ilk işimde müşteri sunucularını ssh ile yönetmem gerekiyordu ve bu sunucularda yalnızca asgari kurulum vardı. Çoğu zaman vim bile değil, sadece vi bulunuyordu; o ortamda etkili çalışmanın yolunu bulmaktan başka seçeneğim yoktu.
O deneyim olmasaydı terminalde çalışmaya başlamanın acısına katlanır mıydım, emin değilim.
Ama bir noktada orada çok fazla zaman harcadığımı hissettim. tshark ve jq, eski usul bash/awk/grep ve gnuplot ile yeniden komut satırına döndüm; sonrasında Python kullandım ama hâlâ tshark çıktısını kullanıyordum.
Sonunda pcap ve pcapng ayrıştırıcıları, ethernet-ip-udp/tcp işleme ve eksiksiz bir Java IDE bile geliştirdim; bir daha geri dönmedim.
Tekrar tekrar kullanmam gereken tüm veri yakalama ve keşif araçlarında da aynı dolambaçlı yoldan geçtim.
Bu tür araç iyileştirme yineleme aşamalarından geçen tek kişi ben değilimdir; bunu açıklayan, iyi adlandırılmış bir ölçek olsa güzel olurdu.
Terminal sonsuz derecede daha fazla yetenek verir, ama düzenli olarak yaptığınız işler muhtemelen 20 civarındadır. Eğer o 20 şey her şeyse, öğrenme eğrisi yüzünden ikna etmek zordur.
Örneğin terminaldesiniz ve build script’ini bulmak istiyorsanız
cat packages.json | jq .scriptsgibi bir şey yapabilirsiniz.Terminal içindeyken faydalıdır ama VSCode’daysanız
ctrl-p -> packages.json -> ctrl-f -> scrile biter; hatta pratikte daha az tuş vuruşu gerektirir.İnsanların iş akışları gerçekten çok kişiseldir; kimseye değiştirmesini söylemem, ama benim durumumda projeyi yalnızca metin olarak ele alan araçlar yerine proje yapısını anlayan araçları tercih ettiğim için IDE bana daha uygun.
Komut satırı uygulamaları grep, sort, cp, git, ls, tar gibi, kabuğa komut yazarak etkileştiğiniz araçlar demektir. Genel kullanımını biliyorsanız script’lerde de kullanabilirsiniz; dolayısıyla pipeline’lar hâlinde birleştirilebilirler.
Metin tabanlı kullanıcı arayüzü uygulamaları ise Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander, Claude Code gibi, kullanırken terminali ele geçiren etkileşimli uygulamalar demektir.
Bunlar pipeline’lar hâlinde birleştirilmez. Daha doğrusu, normalde kullandığınız biçimleriyle pipeline’a koyup kullanmazsınız. Mümkünse bu muhtemelen uygulamanın TUI’den ayrı bir komut satırı arayüzü sunmasındandır.
Her sorunu çözerken aynı araç kutusunu kullanabilecek hâle gelmek zaman alır, ama sonuçta daha verimlidir.
Ancak ikna etmesi zordur. Komut satırı araçları olmadan çözmesi zor bir problemi çözmeden önce, bu sadeliği anlamak kolay değildir.
Yine de her işte komut satırını çok kullanıyorum. Genelde bir konsole penceresini açık tutuyorum; build veya test gerekirse Sublime’ın “build system” desteği yerine alt+tab ile oraya geçiyorum.
Vim’i yalnızca ssh gerektiğinde ya da telefonda Termux kullanırken kullanıyorum.
Sublime, VSCode vb. genişletilebilir GUI araçları da sonsuz sayıda kullanım senaryosunu kapsar; hatta daha kararlı ve yeniden üretilebilir bir çalışma ortamı sağlar.
Bu tartışmanın bitmemesinin nedeni bence insanların genel olarak kapalı fikirli olması. Başkasının yerine kendini koymak zor; yanılıyor olma ihtimalini ciddiye almak daha da zor.
Sonuçta bu mesele yalnızca acemiler için önemlidir. Yeterince alıştıktan sonra ne kullanırsanız kullanın, üretkenlik darboğazı artık araçlar olmaz. Elbette ed istisna olabilir.
“Klavye ile gezinmenin sık sık fareye uzanmaktan çok daha üretken olduğunu bilmiyorlar” iddiasına gelince, kendisinin daha üretken olduğunu söyleyenlerin önemli bir kısmı bunu aslında hiç ölçmemiştir.
Yıllar boyunca klavye ve fareyle gezinme üzerine pek çok yarışma yapıldı; test tasarımının ayrıntılarına göre bazen bir taraf, bazen diğer taraf kazandı ve farkın oldukça büyük olduğu durumlar da çoktu.
Gerçek sonuçları görmeden önce kullanıcıların daha üretken olduğunu söylediği yöntemin kaybettiği durumlar da az değildi.
Mutlak bir üretkenlik metriğinin peşinde değilim; akışı bozmayan bir ortam istiyorum.
Birçok kişi için fareye uzanmak akışı bozar ve garip hissettirir; çoğu zaman 1 saniye yavaş olmaktan daha kötüdür, çünkü zihninizdeki bağlamdan kopmanıza neden olur.
Benim durumumda çalışırken fare kullanmak doğal geliyor; bu yüzden tüm gezinmeyi klavyeyle yapacak şekilde iş akışımı değiştirmek, bazı durumlarda belki çok az zaman kazandırabilir diye devasa ek çaba harcamak olur.
Kelime işlemci, IDE, dosya yöneticisi gibi okuma, yazma, okuyup yazılanları işleme merkezli araçlarda, kullanıcı kısayolları öğrendiğinde klavye ile gezinmenin daha hızlı ve doğal olduğu gösterilebilir.
Buna karşılık metin dışı görsel bilginin merkezde olduğu araçlarda klavye-fare tartışması çok daha fazla fare tarafına kayar.
Yine de etkili kısayolların menülerden ve ikonlardan çok daha kullanışlı olduğu anlar vardır. CAD ya da 3D modelleme yazılımlarına bakarsanız, kullanıcının yaptığı işin %90’ı görsel olarak gösterilen mekânsal verilerle uğraşmaktır; ama araç değiştirme veya araç ayarlarını değiştirme kısayollarını bilmek çok hızlandırır ve iç içe menüleri sürekli kurcalama ihtiyacını azaltır.
Yazarın kendi aracına aşina olmasını, onun daha iyi olduğunun kanıtıyla karıştırıyor olabileceğinden endişeleniyorum.
Gerçekte tüm araçların ödünleşimleri vardır; bir kullanıcı X aracını Y aracına tercih ediyorsa, bu aptal olduğu için değil, o aracın yalnızca deneyimli kullanıcıların anladığı affordance’larını daha iyi değerlendirdiği için olabilir.
Bir geliştiriciye vim, emacs ve Sublime Text’i ayrı ayrı 10’ar yıl kullandırsanız, hangisinin daha iyi olduğundan emin olamayacaktır. Kişisel tercihleri olur, ama başkalarının neden başka araçları tercih ettiğini de açıklayabilir.
Bu, aşina olmadığı yazılımlara gerçekten bir şans vermemiş olmaktan çıkan bir tartışma gibi görünüyor.
Eski kurt olmanın işareti, bence tüm yazılımlara ve o yazılımları iyileştirme vaatlerine karşı hafif bir güvensizliktir. Uzun vadede tüm yazılımlar sıradanlığa yakınsar.
Sadece, aracın sürtünmesini bir özellik olarak görme fikrine katılmadığını söyledi.
Onun argümanını olduğu gibi alıp Vim’in benim için mükemmel editör olduğunu göstermek için de kullanabilirim. Çünkü Vim’i kullandığımda görünmez olur; bir ölçüde de Vim’i istediğim araca dönüştürdüğüm için.
O, Sublime’ı istediği araca dönüştürmüş. Yine de temel nokta geçerli: Başkalarının kullanacağı bir şey yapıyorsanız, o aracın kullanıcı için görünmez hâle gelmesi güçlü bir niteliktir.
Sıradan, “normal veya yaygın kalite” anlamına gelir.
Bir sonraki CRUD uygulamasını yaparken en yeni ve en iyi, olağanüstü teknolojiye mutlaka ihtiyacınız olmayabilir.
Yazdığım cümleyi alıntılarsak şöyle: “Beni şaşırtan şey, birçok kişinin bu sürtünmeyi, yani aracın sınırlarını aşmak için harcanan çabayı ‘eğlenceli’ kısım olarak görmesi ve bunu aracın harika olduğunun kanıtıymış gibi pazarlamasıdır.”
Bunun benim ya da başka birinin hangi aracı neden seçtiğiyle ilgisi yok; kusurları bir bulmaca oyunu gibi etrafından dolanılacak şeyler olarak görme tavrıyla ilgili.
İyi bir aracın bakımını yapanlar, kullanıcıların aracı gerçekte gördüğünden çok daha olumsuz algılayabilir.
“Bugün 10 kişi hata ya da eksik özellikten şikâyet etti, 9990 kişi sorunsuz kullandı” ile “Bugün 10 kişi şikâyet etti, yalnızca 90 kişi sorunsuz kullandı”yı ayırt etmek zordur. Ama kullanıcı memnuniyetini %90’dan %99,9’a çıkarmak için gereken çaba inanılmaz derecede farklıdır.
Bunun birçok açık kaynak bakımcısı tükenmişliğinin büyük bir nedeni olduğundan kuvvetle şüpheleniyorum.
Memnun olmayan kullanıcılar, memnun olan kullanıcılardan çok daha görünürdür; yeni kullanıcıların artış hızına kıyasla aynı miktarda hata raporu ve özellik isteği üreten memnuniyetsiz kullanıcı oranı düşer.
Sonunda bakımcıda, ne kadar iyileştirme yapılırsa yapılsın algılanan genel kalitenin değişmediği yanılsaması oluşur ve devam etme motivasyonu aşınır.
Bu soruna iyi bir çözüm bilmiyorum. Bariz cevap, iyi çalıştığında daha sık övgü vermek; ama pratikte bu pek gerçekleşmeyen bir kolektif eylem sorununa yakın.
Kişisel olarak bir şey iyi çalıştığında bilerek sık sık ve coşkulu biçimde olumlu geri bildirim vermeye çalışıyorum; ama herkes böyle yapmadıkça büyük bir fark yaratmak zor.
Aklıma şu alıntı geliyor:
“Sürekli eğilip bükülen, telaşlı ve dalkavukça davranan kişiyi her zaman fark ederiz ve muhtemelen ‘Ne kadar alçakgönüllü!’ deriz. Ama gerçekten alçakgönüllü olan kişi göze çarpmaz. Dünya onu tanımaz.”
~ Tito Colliander
“Bir aracın size iyi hizmet ettiğinin en açık işareti, onu fark etmemeye başlamanız, yani görünmez hâle gelmesidir. Kusurlarını bir hobiye dönüştürmediğiniz için kusurları övmez, yalnızca biraz sinirlenerek etrafından dolanırsınız” kısmı, araçtan çok kullanıcıya bağlılık gibi görünüyor.
Elbette farklı araçlar farklı kullanıcıları çekecektir ve güçlü korelasyonları ölçmek de mümkün olabilir.
Ayrıca bu bakış açısında denge eksik. Araçlar asla mükemmel değildir; bazen iyileştirilebileceğini fark edersiniz ve o değişikliği uygulamakla bunun alışkanlıklarınıza etkisini tartmanız gerekir.
Ne kadar uzun süre kullanırsanız bu tür değişiklikler o kadar küçülür; ancak kullanım biçiminin ömür boyu evrilmesi ve aracın da buna göre değişmesi doğaldır.
Oldukça tuhaf bir yorum
Yazarın Vim’in “görünür” olduğuna takılıp Sublime’ın çoklu imlecinin ve özelliklerinin öyle olmadığını ima etmesi garip. Zihniniz artık düşünmeyecek şekilde eğitildi diye bir şey daha az görünür olmaz
Çoklu imleç birçok araçta varsayılan bir özellik değil; etkili kullanmayı da katarsak öğrenilmesi gereken bir şey. Vim tuş bağlamalarıyla aynı
Üstelik Vim, terminale özel kullanıcılar için bir TUI seçeneğinden fazlası. Klavyeyi bedenlerinin doğal bir uzantısı gibi kullanmayı öğrenmiş insanların fareyle sürekli gidip gelmemek için kullandığı tuş bağlamaları da. Sublime’ı 15 yıl kullanmış biri için çoklu imlecin böyle bir şey olabilmesi gibi
“Tek seferlik bir metin refactoring sorununu çözmek için makro oluşturmanın ne kadar ‘eğlenceli’ olduğundan bahseden insanlar gördüm. Ama ne yaptıklarına ve ne kadar sürdüğüne baktığımda dürüst tepkim şuydu: Bunu Sublime’ın çoklu imleciyle 1 dakikada yapardım ya da sadece kısa bir script yazardım.”
Ve “Beni şaşırtan şey, birçok kişinin bu sürtünmeyi, yani aracın sınırlarını aşmak için harcanan çabayı ‘eğlenceli’ kısım olarak görmesi ve bunu aracın harika olduğunun kanıtı gibi pazarlaması.”
Vim makrolarını etkili kullanabiliyorsanız ne güzel. Ama onlarca yıl Vim kullandıktan sonra bile kullanamıyorsanız, bunu ‘eğlenceli’ kısım diye pazarlamamak gerekir
En yaygın duygu, öğrenme eğrisi olduğu ama sonunda buna değdiği yönünde
Ne demek istediğini bilmiyorum. Vim makroları da yazarken doğrudan görsel geri bildirim verir. Kaydederken normalde yaptığınız gibi düzenleme yaparsınız, sonra o düzenlemeyi yeniden oynatırsınız
Yazım sırasında metin üzerindeki gerçek zamanlı etkisini görmeden makro kullanmak teknik olarak mümkün mü bilmiyorum ama ben hiç öyle yapmadım
Merak edip çoklu imlece baktım; avantajı, açıklaması kolay tek bir arayüz olması gibi görünüyor. Pratikte bunun yerine birkaç Vim komutu kullanırdım
Çoklu imlecin kullanılabileceği işlerin çoğunda makrolardan daha iyi olabileceğine katılıyorum. Ama genelde bu tür işler için makro kullanmam
Makroyla yaptığım işlerin çoğu çoklu imleçle yapılabilecek gibi görünmüyor
“Bu durumda çoklu imleç harika ve Vim’de iyi bir alternatif yok” diye bir örnek varsa, yanıldığımı görmek isterim
Bu, çoklu imlecin öğrenme eğrisi olmadığı anlamına gelmiyor. İmleçleri doğru yerlere nasıl koyacağınızı hâlâ düşünmeniz gerekiyor
“Görünmezlik” ifadesini daha önce emacs magit’i anlatırken kullanmıştım
Git çıktısının üzerinde ince bir katman; belirip UI durumundan parametreleri çıkarıyor, alışılmış git komutlarını çağırıyor ve sonra kayboluyor
Hafif ve hızlı. Büyük projelerde öyle değil gibi ama öyle diyorlar