Kıdemli programcının güvenini yeniden kazanmak [kapalı]

Patronum düşündüğü kadar akıllı olmadığımı öğrendi.

Tecrübelerime bir örnek:

Ben genç bir programcıyım ve patronum (kıdemli programcı) ve kendim gibi iki kişilik bir ekip halinde çalışıyorum.

Çalıştığımız şirket için dahili bir web uygulaması geliştirmekle görevlendirildim. Arka ucu ön tarafa yazdım (veritabanı tasarımı zaten yerinde ve sunucu teknolojisi seçilmişti). Web uygulamasını çalışırken gözlemleyerek ilerlememi düzenli aralıklarla kontrol ederdi ve ortaya çıktığı için mutluydu. Web uygulamasını bitirdiğimde, son ürünün ne kadar iyi sonuçlandığına memnun oldu.

Birkaç gün önce kodla ilgilendi, bu yüzden ona hangi teknolojileri kullandığımı söyledim (ön uç için) ve burası güneye gittiği yerdi. Web uygulamasının ön tarafı için bir Javascript çerçevesi kullandım (Backbone.js). Neden böyle bir şey yaptığımı sorduğumda. Benim cevabım, çerçevenin bu uygulamaya çok iyi uyduğunu hissettiğim ve kodu sıfırdan yazmamdan daha iyi bir şekilde yapmama yardımcı olacağıydı.

Yani bu örnek verilen sorum şu:

Eğer kıdemli bir programcınız ve genç programcınızın yeteneğine olan güvenini kaybetmişseniz, güvenini geri kazanmak için çocuğunuzdan ne görmek istersiniz?

EDIT : Harika cevaplar ve destekleyici geri bildirim için herkese teşekkür ederiz!

Yaptığınız ürünü beğenirse, ancak Omurga kullanımınıza sıkışmışsa, her ikisinin de istenen teknoloji yığını hakkında bir konuşma yapmanız gerekir.

Geliştiriciler olarak hazır olan araçları kullanmalı ve bunun sonucunda iş akışımızı sorunsuzca ilerletmeliyiz. Ön ucu sıfırdan yapmanı beklediyse, açık olması ve iyi bir nedeni olmalıydı.

Ürünü ilk kez kullanması, sizin iyi yaptığınız ve yeterince "akıllı" olduğunuzu kanıtlar.

tl; dr İyi iş çıkardınız. Yaşlılarınla ​​konuş ve senden ne beklediğini gör.

Böyle hızlı bir karar vermek için bana çok "kıdemli" görünmüyor. "Kare tekerleği yeniden icat et" anti-pattern yerine her zaman uygun bir çerçeve kullanma eğilimindeyim. Gerçekten kıdemli olsaydı, iyi bir çerçevenin değerini anlar ve bilirdi. En iyi ihtimalle, Backbone.js seçimini başka bir MVC JavaScript çerçevesi üzerinden ve süreçte daha önce sorgulamasını beklerdim. Sizi küçük yaşta düzgün şekilde mentorluk etmeden ve kontrol etmede başarısız oldu ve doğru gelişim yolunda size yardımcı oldu (aklında).

Sanki kendi yönünün (varsayım) yönünün bulunmaması nedeniyle projeyi geliştirmek için doğru seçimi yaptınız ve daha yetkin bir geliştirici olmak için çalışıyorsunuz. Ona kendi çerçeve seçiminizi, neden bir çerçevenin uygun olduğunu düşündüğünüzü açıklamanın ve projenin iyi bir şekilde belgelenmiş ve desteklenmiş bir çerçeve kullanmaktan dolayı kısmen tatmin olduğunu belirtmenin bir değeri olacağını düşünüyorum. Eğer ilerleme kaydedemiyorsanız, gözlerinde daha iyi görünmenin bir değeri yoktur. Bunu sadece sen cevaplayabilirsin.

Cevapların ve yorumların çoğunluğu, siz ve yaşlıların bir çeşit tartışma yapmanız gerekeceği ve yaşlı arkadaşınız seçimlerinizle aynı fikirde olmasa bile kararlarınızı arttırmanız ve savunmanızın önemli olacağı konusunda doğru bir fikre sahiptir. .

Son olarak neyi görmek istediğim hakkındaki sorunuza cevap vermek için:

Küçük geliştiricilerin ayağa kalkıp kararlarını hafif bir hayal kırıklığı olsa bile savunabileceklerini görmek isterim. Eğer üründen memnun kaldım, ancak uygulamadan memnun olmasaydım, o zaman gençlerin ürünü verirken özelliklerinde daha spesifik olması gerektiğini belirtmelerini beklerdim. Onların dayanaklarına dayanmalarını istiyorum, ancak durum böyle olursa doğru seçimi yapmadıklarını da kabul etmelerini istiyorum.

Not: Bana yeni bir şeyler öğrenme fırsatı tanıdığı için profesyonel düzeyde yanlış kanıtlanmayı seven bir kıdemli olduğumu söylemeliyim. Ve takımımdaki diğer kişilerin bir Sprint / görevin sonunda hiç sürpriz yapmaması için işleri nasıl yaptıklarının farkında olmayı seviyorum.

Her şeyden önce, bunun bir başarısızlık değil, bir fırsat olarak görülmesi gerektiğini düşünüyorum. Açıkçası beklentilerde bir uyumsuzluk var ve bunun nereden geldiği, her şeyin yoluna girip gitmesi için ne olması gerektiği açık değil.

İkincisi, bunu mevcut bir başarısızlık olarak kabul ediyorsanız veya istemediğiniz güç ilişkilerini kurduğunuzu düşündüğünüz kadar zeki değilseniz. Bu yüzden, kararları savunulabilir olduğuna inanırsanız, onları bir noktaya kadar savunmaya istekli olmanız gerekir.

Duggieae ile sohbet etmek istediğin konusunda hemfikir olsam da, bu yeterli değil. İçeri girmeye, tasarım fikirlerinizi tartışmaya, yaptığınız şeyi neden yaptığınızı açıklamaya ve akıl yürütmeyi savunmaya hazır olmalısınız. Ayrıca, tek bir doğru cevap olmadığını ve kıdemli programcının farklı bir tasarımı tercih etmek için geçerli nedenleri olabileceğini ve kararlarınızın kötü olduğuna karar vermeden bu nedenleri dinlemeye istekli olmaya devam etmek istediğinizi kabul etmeniz gerekir. bildiklerinize göre (daha iyi bilmeniz gerektiğine karar vermediğiniz sürece, o zaman bu başka bir konu).

Tasarımın genellikle bir takas sorunu olduğunu unutmayın. Bu değişimlerin ne olduğunu tartışmaya istekli olmak ve gelecekte tasarım değişimlerini tartışmak için ikinizin neler yapabileceğini görmek istiyorsunuz. Belki siz ikiniz sadece aynı sayfada olduğunuzu sanıyorsunuzdur? Belki patronun bir aptal (bazen olabilir)? Belki de gereksinimler hakkında bildiklerinize göre yanlış bir karar verdiniz? Bununla birlikte açık bir zihinle ve güvenle girin ve bunun hakkında gerçekten konuşmaya istekli olun.

Düzenleme: Akıllı olmakla ilgili bir şey eklemek istiyorum. Tanıdığım en zeki insanlar, herkesten öğrenecek bir şeyleri olduğunu düşünen insanlar. Kapalı olan ve tek bir doğru yol olduğuna inanan insanlar, tasarım gibi alanlarda yaratıcı bir şekilde iyi kararlar vermekten vazgeçmezler ve her şeyi bir araya getiremezler, herkesin öğrenmeye istekli olanları birbirine bağlayamazlar. İçeri girmek ve fikirleri ileri geri paylaşmaya ve hatta geri çevirmeye istekli olmak hem akıllı hem de kendinden emin olmanın bir işaretidir. Tasarımdaki farklılıklar mutlaka birinin diğerinden daha iyi olması ile ilgili sorun haline gelmez. Yetkili tasarımcıları varsayarak, farklı tasarımlar farklı şekilde optimize edilecektir.

Burada yanlış bir şey yapmadığına dair genel düşüncem var. Üst düzey geliştirici olarak, uygulamayı ve sonuçları nasıl geliştirdiğinize ilgi duymalıydı. Bir proje tamamlandıktan sonra gelip, nasıl yapıldığını beğenmediğini söylemek onun için çok profesyonel değil.

Ancak, asıl sorunuzu yanıtlamak için: Kaybolduktan sonra kıdemli bir kişinin görüşünü nasıl geri alırsınız? Her şeyden önce, nasıl yapmaları gerektiğini düşündüklerini sorun. Eğer anlamadıysanız ve not almıyorsanız sorular sorun. Öğrenmek istediğini göster.

İkincisi, bir sonraki görevinizde, açıklamanın dışında bırakılmış bir şey varsa, fikirlerinizi ortaya çıkarın ve sonra bunları kıdemli dev tarafından yönetin. Nasıl yapacağınızı sormayın, b / c, bu sizin görüşünüze yardımcı olmaz. Ancak, kendi fikirlerinizi ve kendi çözümlerinizi bulursanız, onlara doğru yolda olup olmadığınızı sorun, onlara çalıştığınızı ve işi yapma becerisine sahip olduğunuzu gösterin. Hızlı bir e-posta söyleyerek gibi bu basit olarak olabilir "Hey, ben kullanarak planlıyorum x yaparken y . Herhangi bir düşünce?"

Üçüncüsü, nasıl olduğunuzu görmek için başlarını çektiklerinde, kodunuza bakmadan gitmelerine izin vermeyin.

Temel olarak, iletişim hatlarını açın. Üst düzey geliştiriciniz sizin veya kodunuzun üzerinde görünmüyor gibi görünüyor, bu yüzden adım atmanız ve iletişim kurmanız gereken kişi olmanız gerekiyor. Bir şeyin, başlangıçta düşünülmeden değil, tam olarak düşünülmeyen bir şey bulması daha iyi olur.

Yarasadan hemen önce öğrenmeniz gereken bir şey, bulaşık arasından atılıp atılmadığıdır, çünkü seçtiğiniz çerçeve için kapsamlı bir savunma yapamazsınız ya da bir çerçeve kullandığınız için.

Eski durumda, bir projeye dahil edilmek üzere üçüncü taraf kodunu nasıl değerlendireceğinizi ve seçeceğinizi ve bu kararı üstlerinize nasıl bildireceğinizi ve gerekçeli olarak hazır bulunmaya hazır olduğunuzu bilmeniz önemlidir. Bu öğrenmek zor bir beceridir, ancak tecrübe ile gelir. Ayrıca öğrenmek iyi bir beceridir çünkü bir projeye üçüncü taraf bir kütüphaneyi dahil ettiğinizde, diğer geliştiriciler tarafından tam olarak anlaşılamayan, üzerinde tam kontrol sahibi olmadıkları ve hataları içerebilecek bir bileşen tanıtırsınız. Güvenlik delikleri ve dikkat etmesi gereken diğer şeyler.

Eğer onu sıfırdan yazmadığınız için hayal kırıklığına uğradıysa, bu tamamen farklı bir konu. Çerçevelerin kullanımını (yukarıda tanımladığımlar gibi) caydırmak için iyi bir nedeni olabilir veya belki de bunlara karşı bir şirket politikası veya yapabileceğiniz çerçevelerin seçimini sınırlayabilir. Her iki şekilde de bunu size iletmiş olmalı ve onun için bir başarısızlık olmadığını belirtmiş olmalı. Öte yandan, sadece çerçeve önyargısı olabilir, çünkü çerçevelerin yol açabileceği konulara rağmen, bildiğiniz gibi benim de büyük faydaları var. Her şeyi kendiniz yapmanız gerektiğini düşünebilir, bu “zaten icat edilmedi” sendromu nedeniyle zaten yapılmış ve kamuya açık hale getirilmiş çalışmaları tekrarlamak anlamına gelse bile.

Sizden bir çerçeveyi kullanmakta neden hayal kırıklığına uğradığını açıklamaması, kesinlikle etkili bir şekilde iletişim kurabilmesi için bir başarısızlık. Ne yanlış yaptığını merak etmeni bıraktı, cevabı "hiçbir şey" dediğinde. Ayrıca kendini sorgulamana sebep oldu ve gelecekte kendi inisiyatifini kullanma konusunda daha az eğilimli olman gerekiyor. İyi bir programcının sahip olamayacağı bir özellik varsa, bu bir girişim eksikliğidir. Ve istemeden de olsa eminim, tavrı moralini bozuyor, çünkü görevi nasıl yerine getirdiğine dair küçük bir ayrıntıya adanmış bir iş için bir anda övgüyü çekti.

Sırf kıdemli programcı onu yanılmaz yapmaz.

Takip eden yorumunuz, patronun üzgün olduğunu, yeni bir şeyler öğrenmesi gerektiğini söyledi.

Bahsetmediğin daha fazlası olmadıkça, HIM’e kızardım.

Yeni teknolojiler öğrenmek işimizin büyük bir bölümünü oluşturuyor ve her ekip öğrenmeyi ve kendini geliştirmeyi benimsemeli.

AMA, yönetim endişelenecek başka şeyler var. Karşılamaları için son başvuru tarihleri ​​var, sınırlı veya hiç eğitim bütçesi yok.

Bir insan yönetimi bakış açısından, sizin yerine projenizin 2. safhasında çalışan bir başkası olabilir. Patronunuz, bu işi yapmak için başka bir kulağı işaretlenmiş olabilir ve o kişinin şimdi yeni bir şey için bir öğrenme eğrisi olduğunu biliyor.

Ve şimdi önceki ANCAK AMA ......... bu senin patronların suçun. Eğer yeni ve küçükseniz, en azından biraz rehberlik sağlamalıydı. Daha az bir ölçüde, kullanmak için teknoloji konusunda da rehberlik isteyebilirdiniz.

Eğer kıdemli bir programcıysanız ve küçük programcınızın yeteneğine olan güveninizi kaybettiyseniz, tekrar güvenini kazanmak için çocuğunuzdan ne görmek istersiniz?

Kullandığınız çerçeveyi nasıl kullanacağınızı öğrenmek istemediğinizi söylediğinize göre, soru şu olmalı: " Eğer kıdemli bir programcıysanız ve sizden öğrenme yeteneğinizi kaybettiyseniz junior programcı, kendini çözmek için ne yapmalısın? "

Profesyonel bir geliştirici olarak öğrenmeyi bırakmazsınız. Hiç. Eğer yaparsan, durgun olacaksın. Ve bu bazı bölgelerde iyi olabilir. Bankacılık, çok yavaş hareket eden eski sistemler hakkında bilgi sahibi olmak için sürdürülmesi gereken çok sayıda eski sisteme sahiptir. Bir arkadaşım COBOL'u bir banka için kuruyordu, kaynak kodunun yaklaşık 30 yıl içerisinde dokunulmadığını keşfetmişti (ve asıl yazar bizim üniversitedeki COBOL eğitmenimizdi) ... eski sistemlerin yeni sistemlere entegre edilmesi gerektiği için yeni şeyler öğrenir.

Üst düzey geliştiricinize dönün. " Yeni bir şeyler öğrenmek zorunda olduğu için üzgündü " dedin ve bence bu oldukça yüksek alarm zilleri çalıyor.

Ben her zaman öğreniyorum. Her yıl işverenimin eğitim faturasımı almasını isterken, gerçekte ihtiyaç duyduğum şeye yakın herhangi bir şey harcaması nadirdir, ancak 2000 sterlinlik bir bölgede harcayacağım için istihdam edilebilir olmam gerektiğini biliyorum. Her yıl kendi eğitimimde GBP (yaklaşık 3000 USD).

Eğer kıdemli öğrenciniz yeni şeyler öğrenmiyorsa, o zaman kötü kararlar almaya başlayacaklar (belki de zaten onlar) ve uğraştığınız kodun kalitesi düşecek, çünkü bir sıkıntıya saplanmışlar ve alma ihtiyacı hissetmiyorlar Bu rut dışında.

Çalıştığım en iyi geliştiricilerden biri, hiç inceleme şansım olmadı her türlü şeyi bilen küçük bir geliştiriciydi. Masaya o kadar çok şey getirdi ki bunaldım. Ama gayretlerini takdir ettim ve hiçbir zaman bu konuda "haksız" olmadım. Tüm olanakları değerlendirmek ve onları takıma sunmak için zaman ayırdığı için memnun oldum. Şimdi bir takıma liderlik ediyor ve bana masaya malzeme getiren geliştiricilerden ve onlardan öğrendiklerini anlatıyor.

Üst düzey geliştiricinizin bir şeyler öğrenmesi gerekiyor. Kendi yetersizliklerini gizlemek için duygusal sözcükleri (“yitirmek” gibi) kullanmamalarını öğrenmeleri gerekir, çünkü bu başkalarının güvenini bozacaktır. Yeni çerçeveler öğrenmeye ihtiyaçları var (her şeyi öğrenemeseler bile, ne yaptığını ve bir problemi nasıl çözdüğünü öğrenseler bile ve gelecekte buna ihtiyaç duyuyorlarsa, daha derin öğrenme için zaman harcayabilirler). Ve sürekli öğrenmeye devam etmek zorunda kalacakları bir işte olduklarını öğrenmeleri gerekir.