Üst düzey bir akıl hocası kaç genç olmalıdır? [kapalı]


20

Mağazamızın boyutu dinamik olarak artıyor, bu yüzden birkaç yeni genç geliştirici tutmayı planlıyoruz, ancak yaşlıları çok fazla mentorluk ve eğitim ile boğmak istemiyoruz. Kaç tane (genellikle üniversiteden yeni) genç geliştirici, üst düzey görevlerini hala etkili bir şekilde yerine getirirken üst düzey bir geliştirici mentorunu yapabilir (ve yapmalıdır)?


7
Neden bizden yaşlılara sormuyorsunuz?
Mert Akcakaya

7
@Mert: Onlardan birkaçını sordum ve diğerlerine de soracağım, ancak toplumdan da fikirleri duymak istiyorum (endüstriyel ortalamalar, başparmak kuralları, en iyi uygulamalar vb.), Çünkü bazı meslektaşlarımız bana çok iyimser geldi.
palacsint

Yanıtlar:


23

0 ile 5 veya 7 arasında herhangi bir yerde (ya da öylesine).

Düşük taraf argümanları:

  • Herkes bir akıl hocası olmaya hazır değil. Birisini yeni bir kariyere korkutmak için o kadar sert olan bazı geliştiricilerle çalıştım.
  • Kıdemli geliştiricilerin aynı çıktı seviyesini korumasını bekliyorsanız, sayıyı düşük tutun.

Daha yüksek tutar için argümanlar:

  • Bazı geliştiriciler, başkalarının çalışmalarına rehberlik ederek üretken olma yeteneğine sahiptir. Çift programlama bir örnek olacaktır. Eğer bu büyülü kıdemli geliştiricileriniz varsa, devam edin ve daha fazlasını verin.
  • Kıdemli geliştiriciden beklenen çıktıyı düşürmek istiyorsanız, onlara daha fazla genç geliştirici atayabilirsiniz.
  • Neden yönetişimin öğretilmesinde gerçekten iyi bir geliştiriciniz varsa, o zaman bu üst düzey geliştiricinin verimliliğini açıkça görmek ve onlara daha genç geliştiriciler vermek isteyebilirsiniz. Buradaki fikir, uzun vadeli bir kazanç / yatırım (ekibin geliştirme standartlarına daha iyi uyum) için kısa vadeli bir maliyettir (üretim kaybı).

Kıdemli geliştiricilerle sohbet etmeyi ve neyle rahat olduklarını görmeyi teşvik ederim. Herkes mentörlük yapmak istemez. Ayrıca "tam kitaplık" benzetmesini kullanmayı unutmayın: İş yükleri şu anda dolu. Mentorluk yaparak iş yüklerine ekleyecekseniz, yer açmak için raftan başka bir şey almanız gerekir.


17
I have worked with some developers who were so gruff that they would have scared someone into a new career.Seni hatırlamıyorum, ne zaman birlikte çalıştık?
yannis

@YannisRizos Çok daha fazla söyleyemeyiz: +1

11

Doğrudan üniversiteden insanları işe alıyorsanız, üst düzey geliştirici başına ikiden fazla olamaz. Geçmişte uğraşmak zorunda olduğum son üniversite mezunları temelleri iyi biliyorlar, ancak iş dünyasında programlamanın nasıl bir şey olduğu hakkında hiçbir fikirleri yoktu. Onlara profesyonel olarak nasıl programlanacağını öğretmek için zaman harcamanız gerekecek, yazdıkları kodu şirkette oldukları sürece desteklemeleri gerekeceğinin farkına varmaları oldukça şok edici. Ama aynı zamanda onlara işinizi (ve tüm kurallarını) öğretmek, mimarinizi nasıl kodlayacağınızı, kodlarını gözden geçirmeyi, onlara nasıl test edileceğini öğretmek ve sorudan sonra soruyu cevaplamak için zaman harcamanız gerekecektir.


7

Eğer çok sayıda çocuğunuz geliyorsa, diyelim ki> 30, üst düzey bir geliştiriciyi onlara tam zamanlı mentorluk yapmaya adamaya değebilir. İlk işimde, birçoğumuzun üniversiteden yeni çıktığı konusunda işe aldılar ve ilk 6 ay boyunca ipleri öğrenmemize yardımcı olan özel bir ekip üyemiz vardı. Geçişi çok daha kolay hale getirdi ve bize çok şey öğretti.

Sadece bir kişinin işi yapması daha verimli olmakla kalmaz, aynı zamanda ofisinizde mükemmel bir akıl hocası olacağını bildiğiniz tek bir kişi olabilir. İyi bir programcı mutlaka iyi bir öğretmen değildir.


2
+1 "İyi bir programcı mutlaka iyi bir öğretmen değildir." Ancak bu durumda yaşlıya bir akıl hocası değil, öğretmen diyebilirim.
scarfridge

2

Kendi işlerini zamanında yapabilmek için ellerinden geldiğince fazla.

Bu nedenle cevap, kıdemli kişinin hem geliştirici hem de öğretmen olarak ne kadar etkili olduğuna bağlıdır.


1
Cevabınız, gençlerin sayısı değişkenken "işlerinin" sabit kalması gerektiği anlamına geliyor. Bu korkunç bir hata olurdu.
pdr

1
@pdr - Ben böyle bir şey ima etmedim. Bu sizin yanlış çıkarımınız. Dediğim şey, kıdemli bir geliştirici olan bir çalışanın sorumlulukları olduğu ve işverenlerinin verimlilikleri konusunda beklentileri olduğu. İş sorumlulukları özellikle mentorluk içermedikçe, üst düzey geliştirici işverenlerinin beklentilerini karşılamakla yükümlüdür ve bu beklentileri karşılarken üstesinden gelebilecek kadar mentorluk yapmayı seçebilir.
Joel Brown

1
Bir işverenin, bir bireyin değil bir ekibin üretkenliği konusunda bir beklentisi olduğunu ve ekibin bu beklentileri belirlemede en azından kısmen sorumlu olması gerektiğini iddia ediyorum. Bu ekibin yöneticisi, bir kıdemli danışmanı ve hem küçüklerin hem de kıdemli kişinin anladığı diğer sorumluluklar arasında bir denge (0: 100 ila 100: 0 arasında) bir denge kurmalıdır, böylece denge kaldırılırsa, birileri yükselebilir kırmızı bayrak erken.
pdr

1
Bireysel çalışanların kendilerine yönelik beklentileri olmayan herhangi bir organizasyonun, herhangi bir anlamda çalışmak isteyen bir yer olmadığını iddia ediyorum. Bazı kuruluşlar mentorluk için bir "kota" belirleyebilir, ancak 25 yıl içinde gördüğüm vakaların büyük çoğunluğunda - bunların 20'den fazlası sözleşme yaparken, mentorluk işçiler arasında gayri resmi bir süreçtir ve "personel gelişimi" sadece yönetim sorumluluğunu resmi olarak kabul etti.
Joel Brown

1
Bu yönetici, mentorluk beklentisi eklerse, çıktı beklentilerini buna göre azaltmaları gerektiğini anlamalıdır. Kimse bu beklentiler konusunda net değilse, gençler yöneticinin beklediğinden daha fazla mentorluğa ihtiyaç duyduklarında, bir kıdemli yöneticilerini uyaramaz, yani (a) yetersiz teslim veya (b) daha fazla saat veya büyük olasılıkla çalışmak zorunda kalırlar (c) mentorluk görevlerinde başarısız olmak.
pdr

2

Deneyimlerime göre bu oranın nerede olması gerektiğine BÜYÜK bir etkisi olan proje çalışması türünden bahsetmiyorsunuz.

Deneysel şeylere neredeyse otomatik hale getirilebilecek bir çerez kesici tekrarlama ölçeğinde, geliştirici gerçekten işe yaramayacağından bile emin değildir, gerçekten düşük bir orana ve daha sıkı bir şekilde değilseniz, jr devs'i sola doğru tuttuğunuzdan emin olmanız gerekir. sr devs, spektrumun deneysel sonuna kadar düşündükleri bir şey yapmaya çalışıyorlarsa sola doğru giderler, çünkü genellikle aynı anda kendilerini zorlarlarsa jr devs ekibinde etkili bir sürü sürüsü olmazlar. .

Benim görüşüme göre insanlar kadar işe bağlı.


2

Mentorluk yönetmekten daha az resmidir. Mentorlar işe alma, işten çıkarma, inceleme ve disipline doğrudan dahil değildir. Çevre önemli bir faktör olacaktır. Dikkate alınması gereken faktörler şunlardır:

  • sr kalitesi. ve jr. devs
  • şirketin programcıları ne kadar iyi yönettiği / tedavi ettiği
  • sr. dev iş yükü
  • yönetimin jr. geliştiricilerin üretken olması gerekiyor
  • diğer eğitim kaynakları (eğitmen destekli kurslar, referans materyalleri, sertifika gereklilikleri)
  • ekliyoruz. Bu sitede birçok kez insanlar uzun bir takım almak ve birlikte çalışabilmek için gereken ekibin öneminden bahsetti. Daha yüksek beceri seviyesine sahip biri, eğer uymazsa daha fazla mentorluk gerektirebilir.

Mentorluk genellikle belirli düzeyde bir bağ içerir ve çoğu insanın belirli bir ortamda 3-5'den fazla kişiyle herhangi bir kişilerarası ilişki kurabileceğini düşünmüyorum.


İkisinin tamamen farklı işler olduğunu söyleyebilirim. Temelde patron karşısında daha deneyimli takım arkadaşı.
Erik Reppen

2

İdeal olarak bir genç bir proje üzerinde bir akıl hocası ile çalışır. Bu şekilde, kıdemli alt görevleri atayabilir ve bir projeyi tamamlamak için onlarla birlikte çalışabilir. Büyükler ne kadar çok gençleri yönetmek zorunda kalırlarsa, o kadar az iş başarabilirler. Bir kerede bir kıdemli ile çalışan 1 veya 2'den fazla genç istemem. Kıdemli, 2 veya 3 ay sonra diğer programcılara rehberlik etmeye devam edebilse de, iyi bir programcının yaşlıdan orijinalinden çok daha az zamana ihtiyacı olmalıdır. Yani bir kıdemli akıl hocası 20 veya daha fazla kişi için akıl hocası olabilir ama gerçekten sadece 2 veya 3 zamanlarının çoğunu gerektirir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.