Üst düzey bir geliştiriciden gelen tavsiyenin kötü olup olmadığını nasıl anlarsınız? [kapalı]

Kısa bir süre önce küçük bir geliştirici olarak ilk işime başladım ve bu küçük şirkette bana rehberlik etmekten daha kıdemli bir geliştiricim var. Bununla birlikte, henüz kabul edemediğim şeyler hakkında bana tavsiyelerde bulunacağı birkaç kez var (uzmanlar tarafından yazılan konuyla ilgili birkaç iyi kitapta öğrendiklerime karşı çıkıyor, bazı soru-cevap sitelerinde sorduğum sorular da aynı fikirdeydiler) benimle) ve yoğun programımıza göre, muhtemelen uzun tartışmalar için zamanımız yok.

Şimdiye kadar, onu dinleyerek, mevcut iyi uygulamalar olarak öğrendiklerime dayanarak bir karşı nokta ortaya koyarak bu sorundan kaçınmaya çalışıyordum. Özgün noktasını tekrar gündeme getirir (çoğu zaman en iyi uygulamayı söyleyecektir, daha bakımı yapılabilir fakat daha ileri gitmedi), bir not alıyorum (çünkü puanımı sayacak yeni bir nokta ortaya koymadığı için), o evde ve araştırma, ancak herhangi bir değişiklik yapmayın (hala ikna olmadım). Ancak son zamanlarda, yine bana yaklaştı, kodumu gördü ve önerisini neden değiştiremediğimi sordu. Bu 2-3 hafta içinde 3. zamanı.

Küçük bir geliştirici olarak, ona saygı duymam gerektiğini biliyorum, ama aynı zamanda bazı tavsiyelerini de kabul edemiyorum. Yine de, projeyi daha kötü hale getireceğini düşündüğüm değişiklikler yapmak için baskı yapıyorum. Tabii ki deneyimsiz bir geliştirici olarak, yanılmış olabilirim ve onun yolu daha iyi olabilirdi, bu istisna durumlarından biri olabilir.

Sorum şu: kıdemli bir geliştiricinin tavsiyesinin iyi mi, kötü mü yoksa belki de iyi, ancak bugün bağlamında modası geçmiş olup olmadığını daha iyi değerlendirmek için ne yapabilirim? Ve eğer kötü / modası geçmişse, ona bir üst düzey olarak saygı duyduğumu sürdürürken, 'baskılarına' rağmen, kendi yöntemini uygulamamak için hangi taktikleri kullanabilirim?

Öncelikle, üst düzey bir geliştirici olarak, projelere önderlik ettiğim gençlerin endişelerini doğrudan ve doğrudan bana iletmelerini bekliyorum. Eğer aynı fikirde değillerse, bu tamamen benim için sorun değil. Bazı durumlarda, endişeleri konusunda harekete geçeceğim. Çoğu durumda, kaygıları , mantığın kısa bir açıklamasıyla bir kenara bırakılır , geliştiricinin kendisine saygısızlık etmemesi, fakat aşağıdaki gibi başka bir nedenden ötürü bir kenara atılır :

1. Küçük, alındığı kararı anlamak için eldeki tüm bilgilere sahip değildir. Bazı durumlarda, küçük bir açıklama geliştiricinin endişeyi aşmasına ve zor durumlarla başa çıkmasına yardımcı olabilir.
2. Junior BAD bilgisine sahip. Aslına bakarsan, sen küçüksün. Bu, yazılım açısından genç olmanın eşdeğeri. Çok fazla harika fikriniz olduğuna eminim, ama her şeyi bilmemeniz mümkün. En dayanıklı genç geliştiricilerin, kod için, şirket ve dünya için neyin en iyi olduğunu bildiklerine inananlar olduğunu düşünüyorum. Bu geliştiricilere alçakgönüllülükle daha iyi hizmet verilir.
3. Belirli bir şekilde bir şey yapma kararı yaşlıların başına geldi. Sonunda hala kıdemli biri için çalışıyor. Aslında bir şeyi yapmanın daha iyi bir yolu, bir şeyi yazmanın daha verimli bir yolu veya işi yapmanıza yardımcı olacak daha iyi bir yazılım / donanım olabilir. İş yine de kararları alıyor. İşletme yöneticileri, direktörler, VP'ler vb. Genellikle geliştirme sürecini etkileyen kararlar alır. Bunlar yaşlıların kontrolünün ötesinde ve gençler bundan şikayet ettiğinde, tek yaptıkları yaşlıların stresine katkıda bulunmak.
4. Sadece düz dışarı kıdemli kıdemli dikkate almak için zaman yok. Son tarihler vardır ve bazen değişen kalıplar, uygulamalar ve davranışların ortasındaki davranışlar bu son tarih için maliyetlidir. Doğrama bloğundaki boynu olduğundan, ürünün işlevsel ve zamanında çıkarılması "mükemmel yazılmış" olmaktan çok daha önemlidir.

Bunlar sadece kafamın üstünde düşünebildiğim şeyler. Bir fikrin, uygulamanın, kavramın senden daha yüksek bir kişi tarafından reddedilmesinin veya atılmasının bir çok nedeni var. Birçoğu tatsız, ama hepsi hepimizin insan olduğu ve hepimizin fikirleri olduğu gerçeğine bağlı. Onun düşüncesi şu anda sizin için sayısal olarak üstündür.

Bu kavramları göz önünde bulundurarak endişelerinizi üst düzey geliştiriciye sunmaya devam etmelisiniz. Boşlukları doldurabilecek başka bir üst düzey geliştirici bulun. Pek çok üst düzey geliştirici bulundukları yerdedir çünkü yazılım konusunda insanlardan daha iyidir. Bazıları oldukları yerde, çünkü stajyerlerindeyken kimin kıçını öpeceğini biliyorlardı. Birine mentorluk yapmanın ve dürüst görüşlerini almanın ne demek olduğunu gerçekten anlayanı bulun. Sizinle aynı fikirde olmayabilir ve sahip olmadığınız boşlukları doldurabilirler. Sizinle hemfikir olabilirler ve amacınızı yükseltmek veya durumunuzu daha iyi hale getirmek için yardımcı olabilirler.

Hiçbir zaman bir isyan çıkarmamalısın. Kalbinize yolunuzun doğru olduğuna inansanız bile, takip etmeniz gereken bir talimat verildi ve bunu izlemelisiniz (açıkça yasadışı olmadığı sürece). Bu talimatları izlemekte sorun yaşıyorsanız, nedenini ortaya çıkarmak isteyebilirsiniz, çünkü herhangi bir yazılım üreten birçok şirkette bu davranış biçimini çok yaygın bulacağınızı keşfedeceksiniz.

En iyi seçenek, işinizi etik ve profesyonel bir şekilde yapmaya devam etmektir. Örnek bir şekilde tamamlamanız istenen yazılımı alın ve bu durumdan terfi ettirilerek durumdan kurtulun. Promosyonlar gelmezse, diğer departmanlar veya şirketlerdeki fırsatları takip etmek için birçok referansınız ve deneyiminiz olacak.

Üst düzey geliştiriciye saygı gösterin. Projenin başarısı için sizden daha çok bekliyor. Sorumluluğu olduğu için otoriteyi de aldı. Bir şeyi değiştir diyorsa o zaman yap.

Olduğu gibi, bir problemle karşılaştığınızda endişelerinizi sunmaktan çekinmeyin.

Son olarak, onunla oturun ve ona burada yazdığınız aynı soruyu açıklayın. Belki de büyük bir şeyi kaçırıyorsunuzdur, belki de önerilerinize daha fazla cevap verecektir, ya da tavsiyelerinin kötü olduğunu düşünüyorsanız, onu karanlıkta tutmayın.

Bu olduğunda, yapmanız gereken şey üst düzey geliştirici ile konuşmanızdır . Belki de kodla veya teknik / iş gereklilikleriyle ilgili olmayan bir şey biliyordur. Eğer öyleyse, öğrenmelisin.

Bunu özel olarak yapın. Zorlu otorite olarak görülebilir ve bu tür şeyler en iyi bire bir yapılır. Kıdem tazminatını kabul edip saygı göstererek uzlaşmaya ve işbirliği yapmaya istekli olun, ancak sorularınızı cevaplandırmakta ısrarlı olun. Duruşma yerine, işbirliğine dayanan çerçeveden yaklaşın. Ondan sana akıl hocası istemesini düşünebilirsin.

Günün sonunda, kendi fikirlerinizi (adil olmak gerekirse, nispeten yeni ve denenmemiş olan) onunla dengelemeniz gerekir. Belki de haklısın, ama daha deneyimli bir insandan öğrenmek için elinden geleni yapmalısın, böylece daha bilinçli bir karar verebilesin. İyi bir üst düzey geliştirici, küçük geliştiricilerle bile işbirliği yapma, rehberlik etme ve öğrenme fırsatını memnuniyetle karşılamakta ve fikirlerinin yapıcı bir şekilde zorlanmasını memnuniyetle karşılamaktadır, çünkü bazen yanlış olduklarını da bilmektedirler.

Sık sık söyleyişin, sağduyulu bir yaklaşımdan geçer. Üst düzey geliştirici unutmayın edebilir proje hakkında daha fazla biliyorum ama şeyler yapmak için doğru yolu hakkında daha fazla bilmiyor olabilir. Senden ne ne derse ölçmek zorunda - ne o karşısında sinekler ne diyor karşılık sana kötü tavsiye veriyor onun bahisçiler iddia (yani insanları ondan daha kıdemli; ille Şirketinizde ... Bahsettiğim değil yazılım geliştirmenin doğru yolu hakkında ya da en çok endüstri tarafından kabul edilen en iyi uygulamalarda kitaplar yayınlayan ya da yazan, iyi bilinen "ünlü" geliştiriciler).

İşte bir üst düzey geliştiriciden (ya da herhangi bir geliştiriciden) "kötü tavsiye" örneği: Gevşek bir çiftlemenin ne olduğu ve neden iyi bir şey olduğu konusunda tamamen bilgisizlerse ve kodun tamamını girmeniz istendiğinde, diyelim ki, kod -Bir ASPX dosyası, üst düzey geliştirici clueless olduğu ve onun tavsiye dinlenmemesi gerektiği açıktır.

Öte yandan, size sistemdeki belirli bir modülün nasıl çalıştığını anlatıyorsa, tekrar tekrar dinlemek en iyisidir, söylediklerinizi doğru gelişim ilkeleri karşısında tükürmediğinizi söyler.

İşte benim kural kuralım: Bir şirketteki kıdemli bir geliştirici, en uzun süreye sahip geliştirici olabilir; Gerçek bir beceriye sahip olmayabilir. Alanınızdaki en saygın geliştiricilerin bazılarının söylediklerine karşı çıkan şeyleri mi söylüyor (ondan çok daha fazla deneyime sahip ve çok daha yetenekli ve saygı duyulan insanlar)? Eğer öyleyse, çok aşırı durumlar olmadığı sürece şansı kötüdür.

Aşırı önyargılı bakış açısı için tam teklifleri / anlaşmazlıkları bekliyoruz.

Üst düzey geliştiricinin görüş noktasını anlamak zor olabilir ve evet, işleri yanlış yoldan aşağıya sürüklüyor olabilir, ancak büyük projeler söz konusu olduğunda tutarlılık daha önemlidir.

50 kod geliştiricinin hepsinin kendi kodlama stillerini, standartlarını, metodolojilerini ve tasarım modellerini takip etmesi tamamen kaos olacaktır. Eğer işler yanlış yapılıyorsa, her zaman farklı türde yanlışlardan ve doğru yapılan bazı şeylerden sürekli olarak yanlış olmak her zaman daha iyidir.

Bakım yapma, özellik ekleme veya "yanlış" olanı düzeltme zamanı geldiğinde, mevcut tasarımla ilgili sorunların önceden bilinmesi çok daha kolaydır.

Saygılarımla aynı fikirde olmak iyidir, ancak sonuçta sıraya girmeniz en iyisidir. Takımda hileli olan hiç kimse takım oyuncusu olarak görülmez.

Yaşlılar size sektördeki en iyi uygulamayı göz ardı etmeleri için iyi nedenler veremiyorsa, orada zamanınızı boşa harcamayın. Asla ilerlemeyeceksin çünkü çok fazla tehdit ediyorsun, ve neyse, kötü bir kod yığınını korumak için zaman harcamak istiyor musun?

Çoğu geliştirici üniversiteden ayrıldıklarında okumaya son verir. Yapmadınız, bu yüzden zaten en üst% 10'dasınız. Bugünlerde pek çok fırsat var. Eğer şehrinizde iş piyasası yoksa, daha iyi bir kasaba arayın.

Vay, bu senin yeteneklerini göstermen ve göstermen için harika bir fırsat. Kariyerimin başlarında, amirim olan ve herhangi bir karar veremeyen bir karar verdim, bu yüzden bir sonraki yüksek seviyedeki çalışmanın nasıl yapıldığını öğrenmek için bu fırsatı kullandım. Beni terfi ettirdi. Aynısını yapmalısın.

Üst düzey bir geliştirici olarak, bu tür pasif agresif nitelemeler beni çılgına çevirir ve yüzleşmeden sonra sizi kötü bir inceleme yapmaya yönlendirirdi. Mükemmel çözüm, ekibin birlikte yaşayabileceği çözümdür.

Tarz gelince, bu stil rehberiniz ve kökeniniz tarafından belirlenen en iyi uygulamalar tarafından dikte edilmelidir. Tutkuluysanız, bunun için tartışabilirsiniz, ancak bir kez karar verildiğinde, onunla birlikte yaşayın ve bulunduğunuz ekibin sınırları dahilinde çalışın.

Çok iyi bir durumda değilsin ama HLGEM'in de belirttiği gibi, bu pozisyonları kılık değiştirmiş nimetler haline getirebilirsin. Sorunuz çok yönlü, bu yüzden bazı bölümlere yönelteceğim.

Sanırım, bilmiyor. Aynı zamanda, kibir olabileceğini göstermeye çalışıyor, bu yüzden sorular için fazla gelemem.

Bu çok doğru olabilirdi. Sektörde onlarca yıldır var olan ve yazılım geliştiremeyen yetenekli bir yazılım geliştirici var - bir gelişme veya danışmanlık açısından (bir fark var). Deneyim yeni beceriler taze güçlüklerle başa çıkma ve yeni fikirler çalışıyor ve öğrenme geliyor, ama çoğunluk programcı asla dünyanın yarış görerek, onların sadık Visual Basic ve Java araçları ile Bordro Uygulaması üzerinde çalışan ofise bir kanadında hayatlarını geçirmek soğuk gri ofisleriyle.

Orada bu yanlış bir şey . Pek çok geliştirici için tüm istedikleri bu ve durumdan tamamen memnundur - ancak, geliştiricilere tek başına gelecek nesil programcıları teşvik etmek için ideal bir durum değildir.

Bravado ve kibir, yetersizlikleri örtmeye çalışan bir savunma mekanizması olabilir. Bununla nasıl başa çıkıyorsun? Buna karşı koymayın - lideriniz beceriksizse ve patron durumu düzeltmek istemiyorsa , onunla yaşamak zorunda kalacaksınız . Bu, yuvarlanıp ölmek anlamına gelmez, ama birini iyi bir lider olmaya zorlayamazsın .

Ancak, yalnızca kodumu gözden geçiriyor ve yorumlarının çoğu kodlama yönergeleriyle ilgili

İyi bir programcı olamayacağı konusunda haklı olduğumu düşündüren bu. Bu, şu anda sizden daha iyi bir programcı olmadığını söylemek değildir (en azından sektörde uzun süredir daha fazla deneyime ve maruz kalmaya başlayacaktır) ama yine, bu bir etkili kurşun. Kılavuz ilkelerin hepsi iyi ve iyidir, ancak kodun işlevi, etkinliği ve etkinliği bakımından ikinci sıradadır.

Böyle bir durumda ne yapmalıyım?

Yöneticime bu durum hakkında bilgi verdim ve her seferinde "evet" olduğunu söylemesine rağmen liderliğimi değiştirmesini istedim, ancak ciddi bir işlem yapmıyor.

Tüm bu özel hususları yöneticiye ve onu destekleyecek belirli örneklerle sıraladınız mı? Eğer ona basitçe gittiyseniz ve “Yeni bir kurşuna ihtiyacım var” dediyseniz, sizi ciddiye almaz ve bunu teknik bir sorundan ziyade “kişilerarası bir sorun” olarak algılamaz. Bu durumda birçok patronun tepkisi, "kendi kendine işe yarayacağı" umuduyla onu görmezden gelmektir.

İşte bazı öneriler.

1. Durumunuza meydan okumayın - ateşle deneme, eğlenceli olmasa da, daha sonra kariyeriniz için size bazı kritik araştırma becerileri öğretir.
2. Daha fazla dahil olmak için ipucunu almaya başla. Bunu dikkatlice ve saygıyla yapın . O gelene kadar itmeye ve ısrar etmeye devam edin (bu aslında hayattaki birçok durum için işe yarıyor).
3. Senin kurşun Eğer olmayacaktır yer almak size yardımcı olabilecek başkalarını varsa, bkz. Sadece sağım saatleri ile ilgilenen bir terlik dükkanında çalışmadığınız sürece, şirketiniz size bazı ipleri gösterip kodunuzu gözden geçirme konusunda daha fazla deneyime sahip başka bir geliştiriciye aldırış etmeyecektir.
4. Yeni bir işe göz kulak olmaya başlayın. Ben bir "bırakmalısınız" durumda olduğunu söyleyemem ama alan bir yerde olmak kariyerini incitmez senin daha ciddi bir programcı olarak gelişimini.

Belirli bir sorunu çözmek mi daha iyi bir yolu varsa, sadece do IT .

Kodunuz / çözümünüz en iyi argümanınız olsun. Aksi halde size söylenenlere bağlı kalın.

Konuşma konusu olan mesele

Küçükken, belirli bir kod bölümünün olabileceğinin en iyi olmadığı bir durum vardı. Sadece bu konuda tartışmaya yerine, ben sadece o geliştirilmiş SONRA Benim üst düzey sonuçları gösterdi. Kabul etti, çünkü kod daima kraldır.

Tabii ki deneyimsiz bir geliştirici olarak, hatalı olabilirim ve onun yolu daha iyi olabilir, bu yüzden sorum, kıdemli bir geliştirici tavsiyesinin iyi veya kötü / modası geçmiş biri olup olmadığını daha iyi değerlendirmek için ne yapabileceğime dair bir soru.

Deneyimli bir geliştirici olabilirsiniz. Bunu yapana kadar, bir genç olarak sezginin haklı olup olmadığını yargılamak için yetersiz olacaksın ve o zamana kadar önemli olmayacak.

Bu arada, Joel Etherton'ın cevabını okuyun.

Şunu da yapmamayı denememeyi şiddetle öneririm.

Şimdiye kadar doğru olanı yapmış gibisin. Mütevazıydın ve bir karşı bakış açısı getirdin. Sorunuzdan basitçe onun yöntemine uymadığınızı ya da bir alternatif sunup sunmadığınızı söyleyemedim. Alt satırda, başkasının yaklaşımını düşürmeye çalıştığınızda daima net ve düşünülmüş bir alternatif sunun . Görebildiği gibi, işe yarayabilecek iyi bir fikrin var ve işe yarayacak bir fikri var.

Herhangi bir pozisyonda, her zaman optimal altı şeyleri yapmak zorundayız. Eğer gerçekten hoşuna gitmiyorsa, o zaman yaptığınız gibi yapabilirsiniz ve ortaya çıkarmak. Ondan sonra, patronun yolu ya da otoyol. Daha parlak tarafta, bir genç olarak kötü kararlar almanın riskinden büyük ölçüde izole olursunuz.

Sana savaşları seç. Bir saatlik çalışma hakkında konuşuyorsanız, çalışma şeklinize kadar zaman zaman kodunuzu değiştirmeniz gerekecektir. Bir dahaki sefere büyük bir proje alırsanız, başlamadan önce fikirlerinizi sunma şansını önceden isteyin. Fazladan zaman ayırın ve harika bir demo veya prototip yapın.

Şok edici bir şekilde yaptığım şey sormayı kesmek. Başka bir seçenek verildiğinde ben sadece dalıyorum ve onun yolunu yapıyorum ama kendi yeteneğimi eklemek. Yeteneklerinizi geliştirmek için bir öğrenme deneyimi olarak kullanın ve hala eski okulda kalma gereksinimini arttırın.

Sonunda, her kıdemli geliştirici, yeni şeyler yapmanın yollarına dikkat etmez. Bazen, 20 yıl önce başlattıkları dil için harika olan, ancak bugünün dünyasında "sahte" veya "kötü bir koku" olduğu düşünülen eski okul yöntemlerine sahipler.

Bu devam etmenin korkunç bir yolu gibi gelebilir ve öyle. Ama aynı zamanda yaşlılarıma bir şeyler yapma şeklinden çok şey öğrendim. Ama bu gerçekten sadece benim görüşüm. Sonunda işinizde mutlu olmanız ve dikkat dağıtıcı ve gerginliği düşük bir seviyede tutmanız gerekir. Ve şeylere itiraz etmeyerek stresin azaldığını göreceksiniz.

Orada kıdemli kıdem olduğundan dolayı kıdemli insanlara güvenme. Mümkün olduğunca sık otorite meydan. Yetkili bir otorite, herhangi bir soruyu ikna edici şekilde cevaplayabilmelidir. İlk başta onu otorite yapan şey bu değil mi?

Çünkü birilerinin hayatı boyunca batıl inançlara sahip olması, haklı olduğu anlamına gelmez. Unutmayın, orta çağlarda insanlar dünyanın düz olduğuna ve kendinden haklı götlerin bir kısmının şüphelileri öldürdüğünü haklı hissettiklerini düşünüyorlardı. Şüphelilerin haklı olduğu ortaya çıktı. Kötü yorumlar için çok fazla.

Kötü bir derlemeden asla korkmayın. Rengi değerlendiren kör bir adama güvenir misin?

Yukarıdaki iyi cevaplar, "en iyi uygulamalar" veya "daha iyi korunabilir" gibi bir cevabın bir şeyler öğrenme fırsatı olduğunu ekleyecektir . "Bana neden bu yolun en iyi olduğuna dair bir örnek verebilir misiniz, böylece farkı anlayabiliyorum?" veya "Hangi durumlarda bu yol daha başka bir yoldan daha sürdürülebilir olur, bu yüzden böyle bir plan yapmayı öğrenebilir miyim?"

Eğer kıdemli haklıysa, size bir örnek vermek kolay olacaktır. Eğer papağan ise ... ciyakasını kesmesi için ona bir kraker ver ve en iyi olduğunu düşündüğün şeyi yap. Aksi emir verene kadar.

Yaşlıların rolü mentor ise, sorulduğunda nedenini açıklayacaktır.

HLGEM ve Jarrod'un daha önce söylediği gibi, bu gerçekten kılık değiştirmiş bir nimettir. Cevaplarının ikisi de harika ve bazı noktalar eklemek istiyorum.

Lideriniz etki alanında olmadığı için, uygulamanızın bir kısmı için önemli kararlar alırsınız; Ayrıca, uygulamanın nasıl gitmesi gerektiği, ürün kullanıcılarının ne istediği ve yöneticinizin ürün ekibi tarafından kendisine sunulan bir durumu nasıl ele almak isteyeceği konusunda yöneticinizle de yakınsınız. Bir uygulamada bu kadar bilgiyi kaç kişinin alacağını söyle.

Büyük bir takımdayken takım arkadaşlarından ve / veya liderinden yardım alırsın, ama yöneticinin nasıl düşündüğünü ya da ürün ekibinin ne düşündüğünü bilemezsin çünkü bu tür şeyler genellikle senin liderliğinden geçer ve Bir takımda bazı kıdemli devs. Bir kişinin projelerinin taşımasının zor olduğunu kabul ediyorum, ancak madalyonun öbür tarafı o kadar iyiyse neden bir şansı kaçırıyorsunuz? Ne öğrenebileceğinizi öğrenin, öğrenirken eğlenin ve çok zorlaşırsa yöneticinizi Jarrod'un söylediği gibi ikna edin ya da duruma bağlı olarak yeni bir iş / proje bulun.

Tüm kariyerin gibi insanlarla uğraşacaksın. Ve herhangi bir kodlama sorununa en iyi yaklaşım konusunda hemfikir olmadığınız birçok kişi olacak. Yıllar boyunca benim için çalıştığını düşündüğüm en iyi şey, bir soruna baskı yapmaya devam etmeleri durumunda, önlerinde durmalarını ve çeşitli olası çözümler arasında çözümlerini düşündüğünüzü ve çözümün sizde olduğunu düşündüğünüzü söylemektir. Bu durumda en iyi yaklaşım olduğunu düşündüğünüz yerleşmiş.

Şimdi, tavsiyelerine her zaman karşı çıkmayı seçerseniz, zaman zaman sadece birkaç karıştırılmış tüyü yumuşatmak için zaman zaman "tavsiyelerini" vermeniz ve kullanmanız gerekebilir. Her seferinde verilerini reddettiğini hissetmedikleri sürece, o zaman bu aranızdaki barışı korumanın uzun bir yolu olacak.

Ayrıca üst düzey bir geliştirici olduklarını ve bu ortamda sizden daha uzun süredir çalıştıklarını düşünün. Gerçek hayattaki kodlama çoğu zaman en iyi uygulamalara veya toplum tarafından kabul edilen standartlara dayanmaz. Tam olarak ifade edemediklerinden belli bir şey yapmanızı tavsiye etmelerinin bir nedeni olabilir. Dolayısıyla, onlarla aynı fikirde olmasanız bile, tavsiyelerini yalnızca çözümünüzün daha iyi olduğuna inandığınız gerçeğine dayanarak elden çıkarmadığınızdan emin olun.

Her şey denge ile ilgili. Ve sadece kodlama dengesi değil, takım dengesi. Pek çok proje başarısız oldu çünkü geliştiricilerin bunu yapamadığı, ancak birlikte çalışmanın bir yolunu bulamadıkları için.

Kişisel deneyimimden bazı şeyler sunmak istiyorum, burada jzd tarafından yayınlananlara ek bir cevap olarak düşünülmeli ...

1. Başka bir üst düzey geliştiriciye sorun
2. Kendi başınıza araştırma yapın.

Bir profesyonel randevuda, kıdemli biri tarafından mentorluk yapmam gerekiyordu. Bazı şeyleri biliyordu, ama dürüst olmak gerekirse, maalesef bilmiyordu, bu yüzden cevaplarına çok güveniyordu. Bir şekilde söylediklerinin yanlış olduğunu hissettim. Yaptığı şeylerin, benim yaptığım MS sertifikasyonunda belirtilen en iyi uygulamalara aykırı olduğuna dair bazı kanıtlarım vardı. Ondan sonra başka firmalarda çalışan diğer insanlara sormaya başladım (stackexchange o zamanlar tekrar çalışmıyordu) ve cevapları karşılaştırmak için blogları okumaya başladım.

Yanlış olsaydım harika olurdu, çünkü davranışımı değiştirirdim ama değildim.

Son birkaç yılda, çalıştığım her şirkette, üzerinde çalıştığım her projede, neredeyse her yeni işe alımda (beceri / deneyim seviyesine bakılmaksızın) 'farklı' bir şeyler yapmak istediğinde bir şey fark ettim.

Kodlama standartları veya genel mimari veya dil veya metodoloji olabilir. Ama bu her zaman bir şeydir. Çoğu zaman, sadece son kullanıcılarımız için her şey daha iyi belgelendirilmemeli mi?

Sana tavsiyem o adam olma .

Bir gün, bu kararları almak için işe alınan ve ödenen, tekme kıçı kıdemli bir adam olacaksınız. O gün geldiğinde, git! O güne kadar, pozisyonunuzun ne olduğunu anlayın. Bir patronum var, işimdeki tüm işim patronumun mutlu olmasını sağlamak. Maaşım dışında verilen kararları ikinci olarak tahmin etmek değil. Gerçekten emin değilseniz, patronunuz / amirinizle konuşun ve öğrenin.

Genel olarak konuşursak, eski moda yaklaşımı izleyen takımın yarısından daha eski bir yaklaşıma sahip olan herkes, daha yeni bir yaklaşımı takip eden takımın 1 / 4'ü ve yeni bir yaklaşım geliştirmeye çalışan takımın 1 / 4'ü takımda bulunmaktan çok daha iyidir. yepyeni bir yaklaşım.

Açık bir şekilde ortaya konması gerektiğini düşündüğüm tüm bunların altında bir akıntı var: savaşkan olmayın . Onunla ilişkinizi koruyun. Tavsiyelerini bir tuz teli ile almak ve kitaplarda ve bunun gibi sitelerde onaylamak harika, ama ona saldırma. Eğer kıdemli bir geliştirici ve birçok projeden geçiyorsa, salak değildir ve ondan öğrenecek çok şey var. Daha önce yapmış gibi gözüktüğü gibi, onun bakış açısını anlama arzunuzu dile getirin. Yanlış olduğundan ve haklı olduğundan emin olsan bile, bunun tam tersi ihtimalini kabul et (zaten bunu anlıyor gibisin). Tartışmakta olduğunuzu açıkça belirtmeye çalışın çünkü onun bakış açısını daha iyi anlamak istiyorsunuz, yanlış olduğunu kanıtlamaya çalıştığınız için değil.

Ona bir soru sorduğunuzda hemen size geri dönmezse veya cevabı belirsiz ve / veya yararsızsa, sizi uçurduğunu varsaymayın. Burada daha önce de belirtildiği gibi, meşgul ve / veya stresli olabilir.

Sabırlı olmak da harika. Kafanızda farklı yapılması gerektiğini düşündüğünüz şeylerin bir listesini yapın ve bunları uygun zamanda sunun. "En iyi uygulama" nın yanı sıra öneri için gerekçeli olduğunuzdan emin olun. Doğru şeyler yapmak ve hata yapmamak için dikkatli olun, böylece daha sonra argümanlarınızı yaparken güvenilirliğiniz olur.

Şimdiye kadar onu dinleyerek sorundan kaçınmaya çalışıyordum, karşı bir puan yükselterek, asıl noktasını tekrar gündeme getiriyor (çoğu zaman en iyi uygulamayı söyleyecektir, daha bakımı yapılabilir fakat daha ileri gitmedi). .. evde düşünün, ama ... hala ikna olmadım. Ama son zamanlarda ... kodumu gördü ve bana neden önerisini değiştirmediğimi sordu. Bu, 2--3 haftada 3. kezdir.

(İşlemler için hafifçe düzenlenmiş.)

Bu bölüm beni endişelendiriyor. Doğru olup olmadığını görmenin bir yolu, onun ne dediğini anlamaktır. Okuduğum (kendi tarihimde, diğerleri farklı olabilir), mentorun ne dediğini anlamayan ve açıklama istemeyen küçük bir geliştiricidir. Bunu çözmenin bir yolu açıklamasını istemesini istemektir: Bu ondan daha iyi bir uygulama nasıl? Veya bu neden kodumuz için olduğundan daha sürdürülebilir? Buna cevaplarını bilmiyorsanız, gerçekten iyi tavsiye verip vermediğini bilmiyorsunuz.

Beni gerçekten endişelendiren kısım, senden birkaç kez değiştirmeni istedi ve sende hiç söylemedin. İşte onun tarafından bakabileceği bir yol: değişikliği yapmanı istiyor, neden olduğunu soruyorsun, sana (aklı için geçerli) bir sebep veriyor ve değişikliği yapmayı reddediyorsun. Açıklık istemezsiniz, bu nedenle sebebini anladığınızı ve onu değiştirmek için çok tembel ya da inatçı olduğunuzu varsaymaktadır - ikisi de kıdemli bir geliştiricinin sizi düşünmesi için iyi bir şey değildir. İnan bana, bu şekilde itibar kazanmaktan daha çok soru sormak daha iyidir.

Birkaç düşünce:

1 / Çalışıyor mu? Onun yolu çalışıyor mu, çalışmıyor mu? Yolunun düşük olmasının nesnel bir nedeni var mı?

Objektif bir nedenden ötürü, belirsizlik olmadan ölçülebilen bir şeyi kastediyorum (performans, hatalar, kodun uzunluğu ...) Çözümleri işe yararsa ve bunun kötü bir çözüm olduğunu gösteren objektif bir ölçüm yoksa, onun yolunu yapın. Onun yolu daha iyi ... çünkü muhtemelen kod tabanının geri kalanıyla daha tutarlı ve işini tekrar kullanması daha kolay olacak. Bundan hoşlanmayabilirsin, ama konu bu değil, değil mi?

Eğer işe yaramazsa veya önemli metriklere göre daha düşük performans gösteriyorsa, uygulayın, çözümünü çözümünüzle karşılaştırın, sonra ona yolunu denediğinizi söyleyin, ancak bunu iyi bir şekilde yapmasını sağlayamazsınız (ölçümleri verin) ve ona sorun uygulamanızda bir hata yaptıysanız veya farkında olmadığınız bir gereklilik varsa

2 / Yıldız programcıları diyor ki ... Neden lanet olsun? Ünlü programcıları planlama, tasarım, OOP'a karşı prosedür, ünite testi, istisnalar işleme, kaynak kontrolü, vb. Gibi birçok temel konuda birbirleriyle iç içe geçmiş bulacaksınız.

İşlenebilirlikteki 2 çözüm arasındaki tek fark onu tercih ediyorsa, atlayın. Sevmediğiniz bir paradigmada çalışarak ihtiyaç duyduğunuz zihinsel çalışmalardan yararlanabilirsiniz.

Yalnızca olmak istediğiniz insanlardan tavsiye almanız gerektiği fikrine dayanarak, onun gibi olmak istiyorsanız, kıdemli tavsiyenin iyi olduğu cevabıdır.

Sorunlarımın çoğunu forumlara göndererek ve diğerlerinden yanıtlar alarak sıraladım ve yaklaşık 1 yıldır bu şekilde hayatta kalıyorum.

Böyle bir durumda ne yapmalıyım?

Dürüst olmak gerekirse, bu bir çok teknik iş neye benziyor. Gerekirse zor problemleri kendi başınıza (internet ve denizciler yardımı ile) çözebilecek, kendi kendine başlayan biri olmanız gerekir.

Kod incelemeleri alma ve mimari tasarımlarla ilgili yardım alma açısından bakıldığında, iyi yöneticilerim olsa bile, "statik değişkenler bir s_ belirtilmelidir" den daha fazla bir kod incelemesi yapmadım.

Öğrenmeyi ve öğrenmeyi öğrenme fırsatını kullanın; bunlar gelecekte kullanabileceğiniz bir beceri olacaktır.

Bir saniyeliğine, yönetimin gerçekten işin yapılmasında ne kadar yetenekli olduğunuzu anlamadığını düşünüyorsanız, muhtemelen yanılıyorsunuzdur. Yönetim muhtemelen, şu anki liderliğinin seni değiştirip işini devralması durumunda tamamen yararsız olacağını da biliyor.

Sizi yeniden yerleştirmemelerinin GERÇEK nedenleri, onlara sunduğunuz tüm zorluklara rağmen, hala iş için en iyi kişi sizsiniz . İşinize başkasına devretme riskini almak için çok fazla değer verdikleri açık.

Yönetimin zekasını küçümseme ...

Çoğu geliştiricinin kredi verdiğinden daha akıllılar. Yönetmeye başlayana kadar bunu anlamadım. Muhtemelen liderinizin gerçekte ne kadar işe yaramaz olduğunun da farkındalar ama muhtemelen bu sorunu çözmekte güçsüzler.

Size bir resim çizmeme izin verin, A şirketindeki 5 yıllık deneyime sahip Kurşun A beceriksizdir. Yönetici bunu bilir, Lider A'yı işten çıkarması için üst menajere tavsiyede bulunur. Müdür şu anda kötü görünüyor, çünkü Kurşun A'nın yararsız olarak ödenen şişirilmiş bir maaşı var ...

İşte bir başka potansiyel senaryo, Kurşun A önemli biriyle yakın arkadaş. Politik olarak üstlenemeyecek kadar sıcak.

Her iki şekilde de, uzun süredir devam eden bir hata ile büyük kuruluşların kilim altındaki beceriksiz insanları süpürmeleri daha kolaydır, onlara yoğun çalışma ve yıllarca sürecek “deneyim” e uygun TOO MUCH hasarı yapamayan sahte güç verir. . Maalesef birçok kuruluş bunu yapmayı tercih eder, o zaman aslında problemlerle uğraşır.

Elbette bunun nedeni, bu tür bir organizasyondaki yöneticinin, kötü yeteneklerle bu şekilde başa çıkabilmek için kısa vadede her zaman bu tür insanların kuruma getirebilecekleri uzun vadeli sorunları ele almaktan daha iyidir.

Bu nedenle, kısa görüşlü ve potansiyel olarak etik dışı olsa da, birçok geliştiricinin kredi verdiğinden biraz daha akıllı olduğunu kabul etmek zorundasınız.

Ahhh ahhh. Bu soru bana birçok şeyi hatırlatıyor. Her şeyden önce son işyerimdeki yöneticilerden biriyle anlaşamayacağımı söyleyeceğim. Bu bir kişilik sorunu değildi. Bir iletişim sorunuydu. XYZ ve o belirli bir yöneticinin ABC olarak söylediklerimi keseceğini söyledim. Bir yıldan fazla bir süre o yönetici ile çalışmadığım sürece iyi iletişim kuramam.

Geçen hafta sonu. Bir adam benimle singleton hakkında tartıştı / tartışamadı. İyi değiller, ASLA kullanılmamalı ve kesinlikle kullanmaları için bir neden yok dedim. Onu http://www.gmannickg.com/?p=24 ve konu aldığı daha ayrıntılı makaleye bağladımtartışmadan birkaç gün sonra. Başka bir programcının (DudeB) günü, yalnızca uygun olduğunda singleton kullandığını ('asla' ekledim). DudeB bunun hakkında bir şey söylemedi ama DudeB, DudeB'nin hafıza çekişmeli bir projede olduğunu söyledi, çünkü tüm iş parçacıkları singleton'a erişiyordu. Bundan bahsettikten sonra, makaleyi gösterdikten ve hafıza çekişmesinden bahsettiğimde tartıştığım adam, kabul ettiğimi kabul etmemiz gerekeceğini söyledi çünkü singletons hakkında konuşmaktan hoşlanmıyorum (ama bu yazıyı yazıyorum)

Nokta. Bazen bu adam gibi yanlış ölmüş olabilirsin (belki biri yorumda benimle singleton hakkında anlaşamayacak). Durumumda, üst düzey programcım olan menajerimle birlikte, açıkça yapmam istendiği şeyi yaptım ve o işyerinde bir daha asla kaliteyi ciddiye almadım. İzin verildiğinde yapmayı tercih ettiğim şeyi yaptım ama her zaman yapmam isteneni yaptım, ama aynı fikirde olmazsam, en azından bir kere ortaya çıkardım.

Bu konuda tamamen farklı / tartışmalı bir fikrim var.

Çoğu zaman insanlar çoğu sektör için karı maksimize etmek ve kaybı en aza indirgemekle ilgili nihai hedefi izlerler. Bunun kalpsiz (dolayısıyla olumsuz noktalar) olduğunu biliyorum, ancak sonuç üretmeyecekseniz tecrübe ve sadakat çok az önemli.

İnsanlar, şirketin doğrudan sonuçları üzerinde çok az etkisi olan, bunun hakkında tartışılması gereken son derece dolaylı dakikalara kapılabilirler.

Bir konuda haklı olduğunuzu düşünüyorsanız, en iyi bahis, bunun nasıl daha iyi ölçülebilir sonuçlar doğuracağını göstermektir .

Başlangıçta bunu yapmayı denerdim, günün sonunda, yaşlılara karşı direncin en azından biraz daha tecrübe ve saygı kazanana kadar boşuna olması muhtemeldir. Bunu bir öğrenme deneyimi olarak kullanın ve hala aynı şekilde hissediyorsanız 2+ yıl içinde başka bir şirkete geçin. Bu, yeni işvereninizi etkilemek için sizin ve yaşlılarınızın iyi fikirlerinin bir kombinasyonunu kullanabileceğiniz zamandır. Elbette, kariyerinizde daha önce aldığınız kararların kötü olduğunu düşündüğünüz nedenlerin bir kısmını anlamaya başlayabilir ve bir noktada sizin için çalışan küçük bir geliştiriciniz olabilir.

[Repost: çünkü bir şekilde burada ikinci bir hesap oluşturdum]

Ancak son zamanlarda, yine bana yaklaştı, kodumu gördü ve önerisini neden değiştiremediğimi sordu .

Bunların öneri veya emir / talimat / direktif / ne olduğu konusunda net olmalısınız.

Öneri = Ben böyle yapmanın daha iyi olacağını düşünüyorum; ama bu senin seçimin.

Sipariş / vb. = Bu şekilde yapılmasını istiyorum; ve bu benim seçimim.

Bu gerçekten bir öneri ise, istediğiniz gibi yapın ve kodunuzun geçmesine izin verin. Eğer bu bir emirse (ve bu akıl hocası size bu şekilde yetki veriyorsa) - dediklerini yapın.