Programlamayı öncüye yönlendirmeyi tercih eden bir aday programcı için seçenekler [kapalı]


19

Bu yılın başında ekibimizin baş geliştiricisi farklı bir departmana taşındıktan sonra baş geliştirici rolüne terfi ettim. Yaklaşık 5 yıllık iş deneyimim var ve kullanılabilirlik ve geçmiş performans nedeniyle, yönetimin projeye liderlik etmek için birincil tercihiydim. Biraz endişeliydim ama kariyer gelişimi ve deneyimi için iyi bir fırsat olduğuna karar verdim, bu yüzden kabul ettim.

Ama şu ana kadarki sonucum, önceki geliştirici konumumdan neredeyse hiç hoşlanmıyorum. Birkaç geliştiriciden oluşan 5 geliştiriciden oluşan bir ekibi başarıyla yönetmiş olmama rağmen, neredeyse hiçbir koda dokunmuyorum. Bunun yerine kod incelemeleriyle birlikte planlama ve tasarım ve ekip yönetimi gerçekleştiriyorum. Daha birçok şeyi takip etme ve ekibe atanabilmeleri için planlanan görevlere sahip olma ihtiyacı, kelimenin tam anlamıyla her gün başım ağrıyor. Nadiren fazla mesai yapmama rağmen, işten ayrıldığım her gün en çok yanmış hissediyorum ve sonuç olarak iş dışı zamanımdan keyif aldığımı bile sanmıyorum.

Öyleyse sorum: böyle bir durumu nasıl ele alırdınız, ya da nasıl hallettiniz? Benzer durumdaki insanlar için, ekibinizi, görevlerinizi ve işinizden keyif almanızı sağlayan zamanı daha iyi yönetmenin yollarını buldunuz mu? Yoksa daha kalkınma odaklı bir pozisyona geri dönmenin bir yolunu mu buldunuz? Baş geliştirici pozisyonlarının neredeyse her zaman daha yüksek bir maaş ödediğini biliyorum, ancak kendimi şu anki işimden zevk aldığımdan daha az para ve promosyonları önemsediğim bir noktaya geldiğimi görebiliyorum.

En az bir yıl boyunca ayarlamaya çalışacağımı düşündüğüm için bunu yönetimde kimseyle tartışmadım.


"Bunu yönetimde kimseyle tartışmadım". Neden yeryüzünde değil? Koşun, yürümeyin, yönetin ve açıklayın. İyi bir şirket / iyi bir yönetici, sizin ve onların - herkesin yararına olacak şeyleri anlayacak ve yeniden düzenleyecektir. Yine de başka tür bir şirkette çalışmak istemiyorsunuz
Mawg, Monica'yı yeniden görevlendirdi

Yanıtlar:


16

Burada verdiğim cevap, potansiyel olarak neyin işe yarayabileceğine dair en iyi tahminim, ancak kendimi bulduğunuz benzer durumdan çıkmaya çalıştığım için işe yaradığını görmedim. Her şey benim için hala bir öğrenme deneyimi ama takımımda olumlu bir eğilim görüyorum.

Şirketimde bir takım liderine terfi ettim (buna "tasarım lideri" diyorlar) ve ürünü bilen ve yeterli deneyime sahip insanların yetersizliği nedeniyle 2 farklı takımın liderliğini yapmak için gönüllü oldum. Birkaç ay önce "programa yardımcı olmak için" yönetim bu iki ekibin büyüklüğünü iki katına çıkardı.

Yapmaya çalıştığım bir şey ...

  1. Herkesin (yönetim dahil), benimkinin ve herkesin konumunun kalıcı bir görev olmadığını açıkça belirtin. Herkes tabağa çıkmaya, projenin daha geniş bir görünümünü görmeye ve mimari / tasarım kararlarına katılmaya davetlidir. Kararsız bir anlaşmazlık varsa (şimdilik) son sözüme sahip olacağım, ancak şu ana kadar hiç olmadı.
  2. Diğer insanların gelişmesine ve büyümesine yardımcı olmaya odaklanın. Kodlama ve tasarım ve farklı şeyler yapmak için farklı yaklaşımlar hakkında farklı zamanlarda farklı geliştiricilerle (neredeyse felsefi) tartışmalar yaptım. Bu tartışmalardan bazıları gerçek çalışma ile ilgilidir, diğerleri saf düşünce alıştırmalarıdır. 20 yılı aşkın deneyime sahip bir adamım vardı, kitap rafına geri dönüp bir C ++ kitabı aldım çünkü şablon meta programlama ile yaptığım bazı düşük seviyeli şeylerle ilgileniyordu. Bu tartışmalar biraz bulaşıcıdır ve bu konuları yeterince kez ortaya koyduktan sonra, insanlar bu şeyleri kendi başlarına düşünmeye başlarlar.
  3. Diğer insanlara elimden geldiğince yetki ver. Birçok şeye bakmamıza rağmen, her bir kod incelemesine katılmıyorum. Bunun yerine ara adamlarımız için kod incelemeleri yapıyorum ve bu adamların daha yeşil insanlar için kod incelemesi yapmasına izin veriyorum. Kod incelemelerini "her satırı okuduğumuzdan ve olası her hatayı bulalım" yerine bilgi aktarım aracı olarak görüyorum.
  4. Arayüzler tanımlandıktan ve temel tasarım yerine getirildikten sonra, yeni erkeklerin bile sınıfların iç kodlarını mümkün olduğunca özgürleştirmelerine izin verdim. Evet, bu kodun çoğu mükemmel olmaktan uzak, ancak test ediliyor ve çalışıyor. "Kod kokusu" açısından belirli bir sübjektif sınırı geçiyorsa ve bunu yeniden düzenlememişlerse, bazı sınıfların parçalanması veya yeniden düzenlenmesi gerektiğini öneririm. Bazen acı verici, ama birkaç gün sonra tekrar kontrol edip bir yanıt aldığımda, "itiraf etmekten nefret ediyorum, ama bu kod şimdi çok daha iyi görünüyor", bu aslında bana sıcak, bulanık bir his veriyor.
  5. İnsanlara meydan okuyun. Ürüne eklemeleri için yalnızca özellik atamak yerine, bu özellikleri eklemelerini isteyin, ancak mevcut sınıflardaki işlev / veri üyesi sayısını artırmadan yapın. Yeni bir şey koymak zorundaysanız, mevcut bir şeyi çıkarmanız ve bunun ne olduğunu anlamak için zaman ayırmanız gerekir. Herkes yeniden düzenlemeyi biliyor, ancak başlangıçta fazladan güç olmadan, insanların bunu atlamak için yardıma ihtiyacı olduğu görülüyor. En azından, hemen hemen her kod inceleme sırasında bu noktayı ziyaret etmek için bir noktaya olun.
  6. Her şey DENGE ile ilgili. Takımdaki herkesi inceleyen tek kıdemli kişi olamazsınız. Tüm haftanızı toplantılara ve incelemelere harcayamazsınız. Ekibinizin yaptığı her hatayı yakalamanızı bekleyemezsiniz. Günün sonunda, lider olmak için kendinize zaman ayırmanız gerekiyor, ancak aynı zamanda bir geliştirici olmak için zaman ayırmanız gerekiyor. Kod yazamazsam delirirdim. Her şeyde bile, hala kod yazmak için zamanım olduğundan emin değilim, sadece kod değil, aynı zamanda gerçekten, gerçekten şık şeyler. Ellerimi şablon meta programlama kitaplarında buldum ve Boost'un içinde kazmaya başladım. Bu şeyleri ortaya çıkaran erkekler deli olmalı (iyi bir şekilde). Yönetiminiz sizi neden her şeyin incelenmediği veya bir noob'un başka bir noobs kodunu neden incelediği konusunda rahatsız etmeye başlarsa, sadece denge meselesini açıklamanız yeterlidir ve takımın yeterince deneyimli insanlara sahip olmadığını ve günün sonunda "olan budur". Ekibiniz kıdemli insanlara sahipse, o zaman güçlendirme ve onlara kendi tasarımlarını / incelemelerini yapma / başkalarına yardım etme özgürlüğü verme ve onlara sadece kod oluşturucuları olarak davranma zamanı. Güçlendirme ile özgürlük gelir ve insanlar özgürlüğü sever. Özgürlük / güçlendirme ile ilgilenmeyen geliştiricileriniz varsa, sorun değil. Her takımın hala saf kodlayıcılara ihtiyacı vardır, sadece denge için çabaladığınızdan emin olun. o zaman güçlendirme ve onlara kendi tasarımlarını / incelemelerini yapma / başkalarına yardım etme özgürlüğü verme ve sadece kod üreteci olarak davranma zamanı. Güçlendirme ile özgürlük gelir ve insanlar özgürlüğü sever. Özgürlük / güçlendirme ile ilgilenmeyen geliştiricileriniz varsa, sorun değil. Her takımın hala saf kodlayıcılara ihtiyacı vardır, sadece denge için çabaladığınızdan emin olun. o zaman güçlendirme ve onlara kendi tasarımlarını / incelemelerini yapma / başkalarına yardım etme özgürlüğü verme ve sadece kod üreteci olarak davranma zamanı. Güçlendirme ile özgürlük gelir ve insanlar özgürlüğü sever. Özgürlük / güçlendirme ile ilgilenmeyen geliştiricileriniz varsa, sorun değil. Her takımın hala saf kodlayıcılara ihtiyacı vardır, sadece denge için çabaladığınızdan emin olun.
  7. Zamanınız değerlidir. Ekipten, cevap almadan önce birkaç saat bekleyebilecekleri tüm kritik olmayan soruları e-postayla göndermelerini isteyin. Soru sorulduğunda, tüm ekip üzerine kopyalanmalıdır. Sonunda, gününüzde bir mola verdiğinizde, konuya bir göz atabilir ve kişiye yardımcı olabilirsiniz, ancak birçok kez, başka bir kişi sizi cevap için zaten dövmüş olabilir ve hiçbir şey yapmanız gerekmez. Açıkçası lider olarak, hala kendimi erişilebilir kılıyorum ve bu gerçeği açıklıyorum çünkü hedeflerimden birinin, takımdaki hiç kimsenin ilerleme kaydetmeden uzun bir süre sıkışıp kalmamasını sağlamak olduğuna inanıyorum.
  8. Ekibinizin iletişimi daha etkili hale getirmek için mümkün olduğunca çok araç kullandığından emin olun. Örneğin, bir wiki sitemiz var ve aynı sayı birden çok kez ortaya çıktığında, wiki sayfası oluşturmak için yardımcı olduğum son adama soruyorum.

1
+1 mükemmel cevap, birçok pratik tavsiye. Yetki devri ve dengeleme, sürekli geliştirilmesi ve iyileştirilmesi için son derece önemli becerilerdir.
Péter Török

Mükemmel tavsiye. Özellikle # 4 için +1; Bu şekilde düşünmediği için insanların çok fazla zaman harcadığını gördüm.
DarenW

Yeni sınıf üyeleri eklemeden özellikler ekleme fikrinizi merak ediyorum. Bu stratejinin işe yaradığını düşünüyor musunuz?
Makspm

@Maxpm: İşin dışında arabalar üzerinde çalışmayı seviyorum. Ayrıca elektronik ve donanıma uğraşmaya çalıştım. Bir sürü şeyi eve getiriyorum. Sınıflara yaklaşımım, eşimin benimle birlikte aldığı yaklaşım: "eğer bir şey getirirsen, bir şey çıkarmalısın". Asla yeni bir değişken veya yöntem eklemeyin demiyorum, ama sadece basitçe ekleyemeyeceğiniz belirli bir eşik geliyor. Kodunuz büyürse, büyük bir yığın alabilir ve bir veya daha fazla bağımsız birime ayırabilirsiniz. Sonra büyük monolit yerine, yapı taşlarına sahip olacaksınız ve gerektiği gibi hareket edip yeniden düzenleyebilirsiniz
DXM

@Maxpm: eklemeyi unuttum ... Evet, bu strateji son derece iyi çalışıyor ve herkesin aşina olmasını tavsiye edeceğim SOLID ilkelerinin tam merkezinde yer alıyor. Kodumda çürümeyle uğraşmak zorunda kaldığımdan beri epey zaman geçti.
Ocak'ta DXM

4

Bunu yönetimde kimseyle tartışmadım

Bunun muhtemelen yardımcı olacağını biliyorsunuz. Rahatsızlığınızı bir pozisyonla iletmek, hiçbir şeyi somut olarak belirtmek zorunda değildir. Yönetimin hangi kartları tuttuklarını bilmesini sağlar ve iyi bir yönetim ise en iyi potansiyelinizi kullanmanın bir yolunu bulmaya çalışır. Daha azına razı olma.


3

Projeniz sona erdiğinde, şirketinizde veya dışında daha programcı odaklı bir pozisyon arayın.

Daha az yönetim ve beceriler konusunda daha teknik "eller" olmasını istediğiniz yönetim ile tartışın.

Olası bir geliştiriciye karşı PM pozisyonundaymışsınız gibi görünür. Bir lider geliştiricinin daha fazla kodlama olduğunu düşünürdüm.


Evet, ben de öyle. Maalesef bazı projeler böyle, benimki öyle değil. Bunu yönetmek için yeterli teknik malzeme var, bunu% 95 oranında yapmam gerekiyor. Gelecekte bunu değiştirmeye çalışacağım.
William Fontaine

3

İşverenlerin bakış açısı :

Eğer şu anki işten hoşlanıyorsanız ve orada iyi bir geçmişiniz varsa, sizi devam ettirmek isterim ve sizin için bir yer bulurdum, böylece onlarla konuşmaktan çok endişelenmem.

Harika bir geliştirici değerli bir şeydir, ancak hokkabazlık eyleminden daha fazla kodlama ve belki de tasarım yapmaya değer olduğunuzu satmanız gerekir.

Bir ardıllık planı oluşturarak onlara sizi destekleyecekleri bir yol verin. Temel olarak şu anki takımda baş ağrısı veren şeyleri yapmakla ilgilenen birini buluyorsunuz, önümüzdeki 6-9 ay boyunca onları eğitiyorsunuz ve görevlerinizi birer birer veriyorsunuz.

Haftalık durum güncellemeleri gibi kolay bir şey seçin:

  • Bir durum güncellemesi yaparken onları yanınıza yerleştirin.
  • Sonraki durum güncellemesinde olduğu gibi yanlarına oturun.
  • Kendi başlarına yapsınlar ve final için çıkmadan önce gözden geçirin.

Ardından, ek sorumluluklarınızın ihtişamını teslim edene kadar, onlara aşamalı olarak ekstra görevler verin.

Bu daha az arzulanan işlerin daha fazla ödenmesinin nedeni, eğer hiç kimse olmasaydı onları yapamazdı, nessacrily değil, çünkü daha yüksek bir beceri ... arz ve talep gerektiriyorlar.

Yine de daha yüksek ödeme yapmaya devam etmek için ... Eğer ben olsaydım etrafta kaldığını duymak isterdim, gerektiğinde bu kişiye yardım edeceksin, yeni çocuklara bir akıl hocası olacak, tasarımcı / anahtar beyin / proje yöneticisi yerine alan adı uzmanı. Temelde bu değerli bir konumdur, başka biri etrafta koşarak ve hokkabazlık eyleminde bulunabilir (daha fazla ödeme için açıkça).

İşvereninize 6-9 aylık bir plan sunacak olsaydınız,

  • Diğer sorumluluklar üzerinde kodlamaya odaklanmaya geri dönmenizin neden daha iyi olduğunu düşündüğünüzün iyi bir açıklaması.
  • Kime teşebbüs etmek ... yoksa birini bulmak zorundalar mı ... bu bence önemli bir karar olacak.
  • Rach Ay 6 ay boyunca yeni kişiye ne gibi sorumluluklar vereceksin
  • Hangi sorumlulukları omuzlu tutacaksınız (tasarım, belki kod incelemelerinde oturanlar gibi).
  • (Orijinal ile şimdi arasında bir yerde) almaya istekli olduğunuz ücretlerde bir fikir olsa da, bunu gündeme getirmelerine izin verin.

Bunu benim için bir plan olarak, bir işveren olarak bir araya getirirseniz, bunun gerçekleşmesi için sizinle birlikte çalışmaktan mutluluk duyarım.

İyi şanslar.


1

Ben senin durumun içindeydim. cevap yöneticinizle olan ilişkinize gelir. Benim durumumda çok iyi bir şeydi, bu yüzden onu bir gün ayırdım ve işten zevk almadığımı, çok stresli hissettiğimi ve kodlamaya geri dönmek istediğini söyledim. Bunu duymak beni terk etmekten çok mutluydu. Bu yüzden bir başkasının Takım Lideri olarak benim almamı ve kodlamaya geri dönmemizi planladık.


0

Gönderinizde açıkça görülmeyen 2 soru:

  • Yazdığınız yazılımdan (Google, Microsoft veya Fog Creek gibi) doğrudan para kazanan bir şirkette misiniz veya bağlı bir işlevde misiniz (bankada veya gıda şirketinde olduğu gibi)?

  • CEO bir teknoloji uzmanı mı yoksa iş rolleri ile yükselen biri mi?

Teknolog CEO'su olan bir yazılım firmasıysanız endişelenmeyin. Kurumsal liderlik değerli geliştiricilerin kim olduğunu bilecek ve onları korumak için ne gerekiyorsa yapacak. Yöneticilerin hepsi "insanları yönetme" veya "bütçeleri yönetme" çizgilerini alan kişiler ise, endişelenin. Dahili bir BT departmanındaysanız iki kat endişe edin. Bu durumda, iyi bir iş-yaşam dengesinin bir geliştirici olarak kalmanın ödülü olduğunu kabul etmelisiniz.

Son bir nokta - sizi mutlu edecek şeyi yapın. Herkesin böyle kariyer seçimleriyle ilgili tavsiyeleri onları neyin mutlu edeceği ile ilgilidir - ve bu sizinle ilgilidir.

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.