Fanboy'larla İlişkiler [kapalı]

Muhtemelen böyle biriyle tanıştık, sadece dilinin tek gerçek dil olduğunu bilen ve bu konuda susmayacak geliştirici. Böyle biriyle nasıl başa çıkıyorsunuz? Kimseyi rahatsız etmek istemiyorum (özellikle işyerimdeki fanboy üst düzey geliştirici olduğundan). Ancak, depoya asla getirmeyen ve başka kimsenin bilmesine gerek olmayan bir komut dosyası yazmam gerektiğinde kendi komut dosyası dili seçimimi kullanabilmek istiyorum.

Bununla uğraşmak zorunda olduğum düşünceler:

1. Güle güle - "Haha evet belki X dili biraz daha kolay, sanırım ben bir mazoşistim!"
2. Onunla git - Yeni bir dil seçmeyle ilgili verimlilikteki düşüşü göze alamadığım için bundan gerçekten kaçınmayı tercih ederim.
3. Dilimi gizle - Bir şey programlarken veya otomatikleştirirken bir dolap programcısı olun ve monitörümü gizleyin.

Bu durum için ne önerirsiniz?

Birkaç şey sorudan atlıyor.

• Gerçekten ıskarta bir senaryo mu? Eğer öyleyse, tartışılması garip.
• Fırlatma betiğinin olduğu gibi kalacağından emin misiniz? Bir çok üretim işi bir zamanlar bir deneme senaryosu olmuştur.
• Eğer terfi edildiyse ve sisteme entegrasyon gerekiyorsa betiği yeniden mi yazacaksınız?
• Dil seçimi tamamen sözdizimsel mi yoksa başka bir alandan gelen bir dil mi?

Fan-boy bölümünü anlıyorum, çünkü bir taraftan, birkaç dilimi korurken, bazen bir fan-boy gibi davranıyorum. Ayrıca yeni şeyler getirmeye çalışan diğer hayranlarla da uğraştım.

Bu duruma ilişkin görüşüm şöyle:

• Yeni bir dilse, bir çöp kutusuna aittir.
• Endüstride kanıtlanmış bir dilse, görev için özelleştirilmişse kullanılabilir.
• Çok popüler olmayan bir dilse, süper serin ve süper hızlı olsa bile bir çöp kutusuna aittir.

Çünkü kimse nasıl bilinmeyen bir dilde güvenli ve hızlı yazılım yazacağını bilmiyor ve geliştiricilerin öğrenmek zorunda olduğu her şeye sahip. Aptal betiğin 20 yıl boyunca desteklenmesi ya da yeniden yazılması gerekecek. 20 yılda ortalama bir mağazada en az 50 geliştirici değişiyor. Her biri yeni bir dilde birkaç fantezi komut dosyası yazarsa, 50 dil çalışma zamanına, ekipte 50 farklı uzmanlığa ihtiyacınız vardır ve kod tabanının 50 dilde buggy kodu vardır. Ve bazı diller artık Windows veya Linux'ta desteklenmiyor. Ayrıca, yedek parça bulunmayan, 10 yıllık özel sunucunun 7/24 ihtiyacı vardır.

Ayrıca, kod tabanının muhtemelen dilden daha fazla çıkacağı hiç kimse gerçekten VB, Silverlight, D, vb.Gibi ölü dilleri desteklemek istemiyor.

Şirket politikasına göre ne kullandığınıza karar veriyor mu? Davanızı ona itiraz edin; eğer hala buna karşı karar verirse, çeneni kapat ve patronun kullanman gerektiğini söylediği araçlarla işini yap.

Sen işe orada, orada oynamaz. Sonuçta sizin elinizde.

Patronunuz olmasa bile, buradaki tüm açıları düşünürdüm. Fortran'ı tanıyorsa ve bir gün tüm kodunu miras alsaydınız ister misiniz? Anında sıfırdan yepyeni bir dil öğrenmek zorunda kalacaksınız , bu çok stresli. Şimdi onun tarafını hayal edin, komut dosyalarınızı Cobol kullanarak yazabilirsiniz ve Cobol'u tanımayabilir.

Takımınızın çoğunun bildiği bir şey kullanın.

"2. Onunla git"

Tek makul cevap bu. Burada harika bir fırsatın var.

• Şirketinizi yeni dili öğrenmek için zaman ve / veya bir kurs ve / veya sertifika ödemeye teşvik etmek için kıdemli programcının yorumlarını kullanın. En kötü senaryo: sertifikasyon ve dil özgeçmişinizi geliştirecek, bir takım oyuncusu olmak için iyi bir öneri alabilir ve başka bir yerde daha iyi bir işe gidebilirsiniz.

• Öğrendiğim her dilden programlama hakkında değerli bilgiler edindim. En az pratik dil bile ( öksürük XSLT öksürüğü ) tatlı bir noktaya sahipti ve ilginç öğrenme fırsatlarıyla doluydu (ve birkaç yıl boyunca faturalarımı ödedi). Sürekli öğrenme, programcı olmanın en büyük faydalarından biridir.

• Tüm harika projeler büyük olasılıkla kıdemli geliştiricinin favori dilini kullanıyor. Bu dili bilmek sizi bu projeler üzerinde çalışabilecek yetenek havuzuna sokar.

• Birisi belli bir işi belirli bir şekilde yapmanız için size para ödüyor. Başka herhangi bir yanıt muhtemelen itaatsizliktir ve muhtemelen kötü sonuçlanacaktır.

Kıdemli geliştirici / mimar normalde bir dükkanda kullanılan birincil dili seçer ve herkesin bu dili kullanmasını sağlar. Bu şekilde, bir şirket belirli teknolojilerde bir bilgi tabanı oluşturur, böylece bir çalışan (siz) tatile çıkabilir ve bir başkası kodunuzu alıp siz giderken düzeltebilir. Ayrıca şirket ilgili eğitim yeteneğini getirebilir ve İK departmanı özgeçmişlerde hangi terimlerin aranacağını bilecektir.

Onun dilini öğrenerek ve iş için kullanarak , en sevdiğiniz dil için etkili bir şekilde savunmak için ihtiyacınız olan politik sermayeyi biriktirirsiniz . Birçok şirketin raporlar için resmi bir altyapı dili ve resmi bir komut dosyası dili vardır. Dilinin nerede olduğunu ve sizin nerede olduğunu, her birinin nerede kısa olduğunu gösteren bir artılar ve eksiler listesi hazırlayın. Bu listeyi, yazdığınız raporlar gibi belirli bir uygulama bağlamında tutmanız gerekir. Listeyi özel ve saygılı bir şekilde göstermek ve onunla tartışmak için onunla bir zaman planlayın. İtirazlarını yazın, toplantıdan sonra araştırın ve iyi karşı argümanlarınız varsa, bir takip toplantısı planlayın.

İyi şanslar!

Belirli bir bağlamda, başka bir dilin daha pragmatik bir seçim olduğunu gösterin.

Kişi C ++ konusunda tutkuluysa ve bir web uygulaması projesi üzerinde çalışıyorsanız, çok zor olmaz. Aynı şekilde, bazı bağlamlar işlevsel programlamaya çok eğilimlidir ve işlevsel olmayan bir dil kullanmak çok akıllıca olmaz.

Notlar:

• Hem sizin hem de tercih ettiğiniz dilin çok benzer olduğu durumlardan kaçının.

  Örneğin, Java'nın C # 'dan daha iyi veya C #' dan Java'dan daha iyi olacağı bir bağlam hayal edemezdim.

• Bir dil seçiminin genellikle öznel olduğunu ve bazı kanıt temelli unsurlardan ziyade geliştiricinin önceki deneyimleriyle daha fazla açıklandığını unutmayın.

  Örneğin finans sektörüne göre bir uygulama yapmam istenirse, Haskell'i daha uygun ve gerçekten heyecan verici bulsam bile Haskell yerine C # kullanırım. Bu seçimin nedeni, C # ile yılların tecrübesine sahip olmam, ancak Haskell söz konusu olduğunda, sadece birkaç öğretici okudum ve asla profesyonel olarak kullanmadım.

Cevap 2) Onunla git.

1. Fanboy'u kapatmanın tek yolu, kendi dilinde akıcı (bir dereceye kadar) olmaktır.
2. Verimlilik kaybı bir sorun değildir. Kıdemliinizin istediği gibi yapıyorsunuz, bu nedenle verimlilik değişikliklerinin proje tarafından gerçekleştirilmesi gerekiyor.
3. Yeni bir dil öğrenmek beyninizin daha iyi çalışmasını sağlayacaktır.
4. Yeni dil öğrenmek konusunda açık olmayı öğrenmek, daha da iyi olmanızı sağlayacaktır.

Kazan-kazan-kazan-kazan. Zevk almak!

Cevap, bununla ilgilenmemenizdir. Onlarla tartışmak, savunucuyu seviyelerine kadar sürükler (sizi deneyimle dövdükleri yerde) ve sonuçta yapıcı değildir, çünkü yakın fikirlidirler.

Kendi dilleri için ya da dilleri için verdikleri argümanları görmezden gelin ve kendi kararınızı verin. Sessizlik sağlarken göz temasından kaçınmak, tek heceli cevap vermek ve yeni bir konuya geçmek gibi olağan teknikleri kullanın. Bunun yerine yanındaki kişiyi rahatsız etmek için onları eğitin.

Buradaki zorluk, fan çocuğunun dili kimliğiyle ilişkilendirmesi ve bu dil ile ilişkili herhangi bir olumsuzluğun kişisel olmasıdır. Saldırmayın veya savunmayın. Görmezden gel.

Bir işte çok az şey gerçekten işe yarayan senaryolar. Yine gerekli olması halinde, wiki'ye veya depoya böyle birçok şey koyuyorum.

Paylaşım seviyesinin altında olduğunu düşündüğüm şeyler bile, takım arkadaşlarım genellikle farklı hissediyorlar. Örneğin, .profile dosyamda bir rgrep takma adı var. Bu sunucudaki gerçek rgrep'e erişimim olmadığı için sadece bir parametre ile bir find deyimi. Bir takım arkadaşı rüzgar aldı ve wiki'de istedi .. Evet, tek satırlık açıklama. Açıkçası uygulama dili hakkında bir tartışma yapmadık - UNIX olması gerekiyordu. Ancak ekipteki diğer kişilerin anlayabileceği şeyleri yapma gereğini vurgular.

Başka bir spin, üst düzey geliştiricinin bu dili kullanmak için bilmediğiniz bir nedeni olması mümkündür. Sordun mu?

Belki sizinki neden daha iyi olduğunu göstermek için her iki dilde de aynı senaryoyu bir kez daha deneyin.

Buğulanmayı denemelisin . Bu, fanboy'un söylediği her şeye (kısmen veya tamamen) katılıyorum, ancak açıkça aksi belirtilmediği sürece kendi işinizi yapın.

Pasif-agresif seçenekler 1,3 daha fazla duygusal sıkıntıya yol açar, bu yüzden bana 2) çeneye al.

Yol için bazı genel öneriler: 4) Kıdemliinizi daha akıllıca dinlemiyorsanız, dil / derleyici tasarımında kendi çalışmanızı yapın. Bir dil seçin ve hangi düşüncelerin içine girdiğini öğrenin. Özellikler, performans ve ifade gücü arasındaki dengenin ne olduğu. Başka ne seçenekler var. Bu tek başına size insanlık dışı süper güçler verecek. NBL'yi bile öğrenin , çok büyük olacak.

Başkaları hakkında görüşler öne sürerek kendini ileri sürmek üretkenliği ve iletişimi engeller. İnsanlar duygusal dürtüden vazgeçmenin yararlı olduğunu düşünebilirler, ancak bu güvensizliklerinde sadece bir bant yardımıdır.

Tavsiye ile alçakgönüllü ve nazik olmak ve kendinizi geliştirmek, bağırsak duygularınızı teknik düzeyde ifade etmek için harikalar yaratacaktır. Daha iyi hissedecek ve ne olduklarını göreceksiniz, çünkü akıl yürütebileceksiniz. Eleştiriyi teknik bir bağlama dışsallaştırdığınızda kızmak zor.