Yöneticiler, bir kişinin iyi mi yoksa kötü bir programcı mı olduğunu nasıl bilebilir?


49

Programlama ekipleri ve bölümleri yapan çoğu şirkette, kod tasarlayan ve yazan programcılardan ve yönetim şeylerini yapan yöneticilerden oluşur. Kod yazmamanın yanı sıra, yöneticiler genellikle ekibin geliştirdiği koda bile bakmazlar ve hatta iş makinelerinde kurulu bir IDE bile olmayabilir.

Yine de yöneticiler, bir kişinin iyi çalışıp çalışmadığını, bir şeyden sorumlu tutulmasını veya belirli geliştiricinin en önemli ve sorumluluk gerektiren bir göreve atanması gerektiğine karar vermelidir. Ve sonuncusu, ama en az değil: yöneticiler genellikle üç ayda bir ikramiye atar!

Yukarıdakileri etkili bir şekilde yapabilmek için, bir yöneticinin bir kişinin iyi bir programlayıcı olup olmadığını bilmesi gerekir - tabii ki diğer özellikler arasında. Asıl soru, nasıl yapıyorlar? İnsanların yazdığı koda bile bakmazlar, programcıların geliştirdikleri bileşenlerin kalitesini doğrudan değerlendiremezler ... ama tahminleri kimin iyi bir kodlayıcı olduğunu ve kimin "o kadar iyi olmayan" olduğunu doğrular. çoğu durumda!

Sır nedir?


24
Harika soru Çalıştığım yöneticilerin çoğu, en kötü geliştiricileri (gerçekten kötü kod ve tasarım) ekibin en iyisi olarak görüyorlar çünkü her zaman zamanında teslim ediyorlar. Öyleyse, süpürüp takip eden takımlarda diğerleri var. Yöneticiler kodu şimdi ve sonra
okumalılar

18
Unutma, programcılar için 'iyi bir programcı' yapan şey, yöneticiye 'iyi bir programcı' yapan şey ile aynı olmayabilir.
GrandmasterB

11
Çoğu zaman yapmazlar.
biziclop

1
Bu cevabını görünüyor yöneticileri nasıl olmalıdır bir kişinin iyi ya da kötü programcı olup olmadığını biliyor musunuz?
Jigar Joshi

2
Hep bir yazılım geliştirme yöneticisi gerektiğini iddia nedeni budur olmak yerine bir programcı ya da olmuş bir programcı. Şimdi onların işi yönetmektir, ama etkili bir şekilde yönetebilmek için, hangisini yönettiğini anlamaları gerekir. Bunu ancak çok uzak olmayan bir geçmişte kendileri programcı olmuşlarsa (gerçekten de yazılım geliştirmedeki yeni teknolojilere aşina tutmaya devam ediyorlarsa) çok iyi yapabilirler.
CraigTP

Yanıtlar:


31

Genellikle bir yönetici bakacaktır

  • Programcı işleri halleder mi?
  • Meslektaşları onlar hakkında ne düşünüyor? Yazdıkları kod?
  • Programcı yönetici ile açıkça iletişim kuruyor mu?
  • Programcı yeni şeyler öğrenmekten hoşlanıyor mu? Başkalarına iyi rehberlik ediyorlar mı?
  • İşleri halletmek için çok fazla yönetim dikkatine ihtiyaçları var mı?
  • Programcı işlerinden zevk alıyor gibi görünüyor mu?

Genellikle çalışanların kodunu göremedikleri (veya çoğu zaman anlamadıkları) doğru, ancak onlar için yukarıda belirtilenler, bir çalışanın işverenleri tarafından uygulanan programlama rolüne ne kadar iyi uyduğunu ölçmek için makul bir vekil olarak hizmet eder. Eğer birileri işleri yapmazsa, meslektaşlarından düşük notlar alır, iyi iletişim kuramaz, farklı teknolojilerle hayal kırıklığına uğrarsa, alıştıkları, her zaman gözetimine ihtiyaç duydukları ve her zaman mutsuz oldukları, bu onların iyi bir göstergesidir. Bu işle iyi geçinmek *

* Ancak, farklı bir bağlamda ve ortamda çok mutlu ve hevesli olabilirler. Belki de sadece itiraz ettikleri türden bir programcı olması ve farklı bir bağlamda çok iyi programlama yapabilirler. “Programcı” farklı yerlerde çok farklı işler anlamına gelebilir. Ancak yönetici çoğunlukla "programcı" rolünü ve bir çalışanın ne kadar iyi uyduğunu önemser.


Bence bu konuların en önemlisi programcı işleri halleder mi? - Sadece ekleyerek tamamlıyorum . Programcı işleri programa göre yapar mı?
Herberth Amaral

2
"Yöneticiyle açıkça iletişim kurar" konusunda ufak tefek bir uyarı: yöneticinin gerçekten anladığını ya da anlayamadığını düşünmekten daha çok ; Bu yüzden neyi anlayabildiğini kontrol etmelisin, çünkü sahip olduğu tavrına rağmen, tamamen farklı bir şey anlamış olabilir.
wildpea

4
Herberth: "İşin bitmesi" (zamanında veya değil) mutlaka yeterli değildir, çünkü diğer ekip üyeleri de onların cesaretlerini toplayabiliyordu.
Cercerilla

2
Ve çok fazla hata olmadan "işleri halleder" de önemlidir. Başka bir deyişle, her zaman geri dönüp bir şeyleri düzeltirler mi, yoksa bir kez bir şeyler yapıldı mı?
perşembe günleri,

23

Yöneticilerin koda bakmadığı iddiasına katılmıyorum. Takımları yönettiğimde, her mühendisin çıktısının bir kısmına baktım - ve büyük olan kod. Ama sadece bir tane değil - e-postalar, tasarım belgeleri, teknik incelemeler - hepsi faktörde.

Ama bu kesinlikle tek faktör değil. Bir adam bir köşede oturuyor ve mükemmel bir kod yazıyorsa, ancak konuşacak bir canavar, sorulara cevap vermeyecek, statüsünü paylaşmayacak ve gelişigüzel sorunlar ortaya çıktığında ödün vermeyecektir. takıma kıymet. Özellikle orta derecede iyi kod yazan, ancak yukarıdakilerin hepsini yapabilen bir adamla karşılaştırıldığında.

İşte size ödülleri verebilecek bir pozisyondayken baktığım bazı şeyler, fakat büyük bir uyarı ile kesinlikle bir bağırsak reaksiyonu olduğu için, bunların hiçbiri ölçülemez:

  • Durum - açık, doğru ve zamanında mı? Tartışıldığında, kişi statünün tepesinde mi yoksa mevcut konularda biraz bulanık mı? Bir şey yandığında kırmızı bayrak açma konusunda kişi doğru karar vermiş midir?
  • Problem çözme - hem sorma hem de cevaplama önemlidir. Kişi ne zaman yardım isteyeceğini veya tekerleklerini süresiz olarak nerede döndürdüğünü biliyor mu? Daha da iyisi, başkalarının problemleri olduğunda, kişi çözümü bulmaya yardımcı oluyor mu veya problemin bir parçası mı? Sorun sizin uzmanlık alanınızda olmadığı zaman geri çekilmek için iyi bir fikir sahibi olmak bile birkaç noktaya değecektir. Ayrıca, grubun veya şirketin dışına çıkmanın ve bunun gibi sitelere ya da diğer internet cevaplarına gitmenin de puanları var.
  • İşleme dikkat - genellikle bu oldukça açıktır - anal olmayan bir şirkette bile, eğer birileri sistemi çökertiyorsa, geride bıraktıkları karmaşada görülür. Diğer insanlar rehberlik veya mimariye uymadıkları için başka birinin özelliklerini temizliyorlarsa, o zaman bir sorunumuz var. Bonus puanlar tutarlılığı ve kaliteyi kolaylaştırmanın yollarını bulanlara gider .
  • Tamamlama oranları - böcekler - karmaşıklık - işleri halletmek, fakat doğru yapmak. Herkese birkaç böcek var, ama adam işleri çabuk hallederse ve adamcağız. Genelde bunun günlük anlamda değerlendirebileceğiniz bir şey olmadığını görüyorum - serbest bırakılmaya, aşamaya ya da mali çeyreğe bakmalı.

Ve diğer insanların girişi. Sık sık, projenin çeşitli bölümlerinden çeşitli mühendislerin sorumlu olduğu bir pozisyondaydım. Bazen takım liderleri ve bazen de sadece belirli bir çıktının sahibini ("yapımcı adam" gibi) sahipler. İnsanlar aşırılıklar hakkında konuşmayı SEVİYOR - kahramanlık eylemleri veya sorunlu çocukların hayal kırıklığı. Genelde bu meseleleri takip etme eyleminde BOTH partileri hakkında çok şey öğrendim.

Ayrıca İnsanları Yönetme konusunda bir faktör var . Hiçbir mühendis tam olarak diğerlerine benzemez. Böylece hepsi aynı ışıkta parlamaz. Bir tanesi mükemmel hatasız kod yazıyor, diğeri ise herkesin kodunu kıran çapraz kesim sorunlarını çözmenize yardımcı oluyor. Biri şahsen harika, biri yazarken daha iyi. Biri saat 9: 00'da tutarsız, biri saat 15: 00'a kadar buradan çıktı. Geri adım atmak, takıma en neyin faydası olduğunu ve kişisel önyargı faktörünün ne olabileceğini bulmak için kesin bir ihtiyaç var (saat 11: 00'e kadar çalışamadığım için sabah saat 4: 00’deki bu parçalayıcıyı öldürme arzusu gibi): 00:00).


2
Yöneticilerin bir kişinin iyi mi yoksa kötü bir programcı mı olduğunu nasıl bilmesi gerektiği açıktır.
Jigar Joshi

Çalıştığım organizasyonlardaki tecrübelerime göre, maalesef her geliştiricinin koduna bakmak için bant genişliğine sahip değilim.
Doug T.

@Jigar Joshi - her menajerin bunu nasıl yaptığını bilmiyorum - performans değerlendirmeleri yapmanız veya önerilerde bulunmanız istendiğinde bunu yaptım.
Bethlakshmi

@ pythagras - karşı sorum olacak "hangi yönetici?" 40 kişilik bir yönetici - hayır, elbette değil. 10 kişiden oluşan bir yönetici - muhtemelen kritik bölgeler olduğu bilinen kişi başı kod taraması başına 1 saat içinde gizlice girmenize neden olmaz. 6 ay boyunca 10 çalışan başına 1 saat kolayca yapılabilir.
bethlakshmi

12

Bu, yöneticinin teknik uzmanlığına bağlı olarak çok büyük miktarda değişir.

  • Çoğunlukla, muhtemelen nasıl iletişim kurduğunuz konusunda sizi yargılıyorlar . Nasıl sen yöneticisi ve nasıl meslektaşları ile iletişim görüldü konum ile iletişim kurar.
  • Yöneticiye daha yakın olan bir lider geliştiriciye sahip olduğunuz için şanslıysanız , yönetici lider geliştiriciden girdi isteyebilir.
  • Yöneticinin birincil sorumluluğunun işleri halletmek olduğunu unutmayın . İş planını karşılamak için çeşitli sonuçlar ve hedefler ürettiğini görmesi gerekiyor. Bir şekilde yapabileceklerse Yani, bak sen sahip olduğunuz gibi sonuç üzerinde doğrudan etkisi , bu senin için iyiye işaret edecektir.

2
Biliyorsunuz, "öncü geliştirici" hipotezi bana Dünya'daki yaşamın uzaylılar tarafından yaratıldığını belirten dışsallık teorisini hatırlatıyor. Evet, bir yönetici gerçekten lider geliştiricinin gözlemlerine güvenebilir, ancak bu geliştiriciyi "lider" yapan yönetici buydu! Hangisi bizi soruna geri getiriyor: yönetim kimin yönlendireceğini nasıl biliyor?
P, 7:11

@Pavel: İlginç bir konuya dikkat çektiniz (henüz ayrı bir konu). Bir öncü geliştiricinin atandığını varsayalım: yönetimin büyük çoğunluğu kararlarına güvenir ve kararlarına inanır (örneğin, seçtikleri kişi).
Jonathan Khoo

if you're somehow able to look like you've having a direct influence on the outcome. Bu, en iyi bonus kazançlarından ancak kötü kodlama geliştiricilerinden en çok yararlanılan şeydir.
İsmail

7

Genellikle yapmazlar.

Bu nedenle programlama "Limonlar Pazarı" dır. http://en.wikipedia.org/wiki/The_Market_for_Lemons

Kod bozuldu ve genellikle siz bilmeden önce 2-3 yıl için değil. Programcılar tipik olarak 18 ay kalır, bu yüzden başarısızlıktaki suçluları asla göremezsiniz.

Yöneticiler, örneğin bir sürümün dört ay ve yüz tekrarlama gerektirdiğine dair sözlerini almalıdır. Belki çok sayıda dağıtım dosyasını elinizle düzenliyor ve durumunuzla karışık hatalar için el ile günlük dosyalarını okuyorsunuz? Daha iyi yapılabileceğini bilmiyorlar.

Dürüst ve profesyonel olun ve gelişmeye çalışın. Tecrübe ile bir yönetici iyi ve kötü davranış kalıplarını görmeye başlayacaktır.


Yöneticilerin kendileri programcı olduklarını (veya oldukları) iddia etme konusundaki soruya kendi yorumumla ilgili olarak. Cevabınızda tanımladığınız şey, tam olarak kendisinin geliştiricisi olan veya olmayan bir yöneticim varken yaşadıklarımdır . Ne yazık ki, bunun gibi birçok yönetici de var.
CraigTP

5

Yöneticiler, bir kişinin iyi mi yoksa kötü bir programcı mı olduğunu nasıl bilebilir?

Büyük kapsamlı bir genelleme ile başlayacağım: çoğu yönetici “kötü” bir programcıdan “iyi” bir programcıya söyleyemez.

Bununla birlikte, çoğu yöneticinin (tanıştığım ya da çalıştığım) bir programcıda "iyi" olduğunu düşündüğü şey, başka bir programcının "iyi" olarak nitelendirdiği becerilerle aynı değildir.

Nasıl yapıyorlar?

Sonuç odaklı bir yönetici "akıllı" ve "her şeyi halleder" gibi şeyleri arayacaktır. İşleri zamanında ve bütçeye göre yaptığınız sürece, eşofman içinde çalışmaya başlarsanız, umursamazlar.

Süreç odaklı bir yönetici “işlerin nasıl yapıldığı” ile daha fazla ilgilidir. Bu, zamanında çalışmak, doğru kıyafetleri giymek anlamına gelir ve TPS raporunda doğru örtü belgesine sahip misiniz?

kişi iyi çalışıyor, eğer bir şeyden sorumlu tutulursa

"Sorumlu" olmak, kod yazmaktan farklı beceriler alır. Bir kişinin bir takıma liderlik etmesi için gerekli insan becerileri varsa, o kişiden bunu yapması gerekir. İnsanları, şu anda yapmakta oldukları işin temel iş unsurlarına dayanarak terfi ettirirseniz, sonunda şimdi yetersiz oldukları bir seviyeye ulaşırlar. Buna Peter İlkesi denir .


Sonuç odaklı ve süreç odaklı yöneticiler arasındaki ayrımı hiç duymadım. Bunun için +1.
mwilcox

4

Açıkçası, her zaman kod okuyabilen ve daha da önemlisi hata izleme sistemine dalan ve ne olup bittiğini anlayabilen bir programlama okuryazar yöneticisine sahip olmak her zaman yardımcı olur, tüm hataların eşit yaratılmadığını ve sadece zamanında kötü kod göndermenin önemli olmadığını bilir. çok için.

Ama bu ideal bir durum. Bir yöneticinin bir programcının ölçüsünü teknik olmayan bir perspektiften alması için birkaç önerim var.

  • Halihazırda belirtilen gereklilikleri yerine getirmek için yapılacak işlerde sorunların nerede olduğunu derhal / düzenli olarak / sürekli olarak vurguluyorlar mı ... ve bunun yüzünden tamamen sinir bozucu oluyorlar (bu, her şeyden önce yazılım geliştirmedir, bu sorunlara sahip olmak yeterince karmaşık değilse bu gerçek bir gelişme projesi değil).
  • Bir şeyden emin değillerse hemen söylerler - yalnızca kendi yeteneklerine güvenen bir programcı bunu gerçekten yapardı (ve eğer beğenmezseniz, kolayca başka bir iş bulabilirler. Tersine, derinliklerinin ciddiye alınmadığını bilen biri gizlenmeye ve örtülü olma eğilimindedir.
  • Takımdaki diğer programcılar diğer programcılar hakkında ne söylüyor / ima ediyor? Eğer yarı saygın bir menajerseniz, özellikle entegrasyon testi / hata düzeltme süresi boyunca, programlama ekibinizle birlikte çalışıyorsunuz. Bu tür bir geri bildirim alamıyorsanız, işinizi yapan başka biri olmalı.
  • Ve en sevdiğim: 'tomcat' programcısı dediğim şey. Kısa bir süre sonra, her zaman aynı programcının masasını (sürekli çalışıyorlarsa ve sorunlu bir konuyu tartışıyorlarsa ve havalı ve eğlenceli webststörün yerleşik bulucusu değil) tartışırken aynı programcının masasında sürekli olarak çalışan çeşitli programcıları fark ediyorsanız ... o zaman başka programcıların bir nedeni var. o kişinin masasına çekiyorlar. Zaten bir takım lideri değilse, o zaman en kısa zamanda bir tane yapılmalıdır.

Bunlardan herhangi biri veya tümü geçerliyse, elinizde iyi bir programcı olması muhtemeldir. İyi bir programcı tarafından sadece kodlama yeteneklerini değil, diğer insanlarla iletişim kurabilmek gibi diğer faydalı şeyleri de derecelendirdiğimi not edin ;-)


Tanrıya şükür ... eğer öyleyse bu benim ilk annem olur. Hiç kimseye açıklık göstermediği takdirde, “kedi sürüsü kedileri” benzetmesinden türemiştir.
nomader

3

Yönetici yazdığınız kodun ne zaman mükemmel olduğunu veya çok büyük bir faktör tarafından geliştirilip geliştirilemeyeceğini bilemeyebilir, fakat bildiği şey şudur: Son teslim tarihine uygun kodla karşılaştınız mı? Diğer insanların yarattığı sorunları çözmek için güvenebileceği bir insan mısınız? Müşteri veya kullanıcı, yöneticisine iletilen bir sorun fark etti mi? Saatinizde büyük bir felaket yaşandı mı (Kullanıcı tablosunu silindi, yedeklemeyi ayarlamayı unuttu, başka bir müşteriden almaması gereken özel mülk verileri olan müşterilere bir e-posta gönderdi, vb. İnsanlar arkanızda iyi mi yoksa kötü şeyler mi söylüyor?


1
Bana politika gibi geliyor ve önceki şirketimden birini hatırlatıyor.
İsmail

2
  1. Kodunuzun yöneticiniz tarafından değerlendirilmediği çoğu durumda, meslektaşlarınız tarafından değerlendirilir (ister kodla, ister kodla çalışmayı denediklerinde resmi veya gayri resmi). Patronunuz, akranlarınızın görüşlerini (resmi veya gayrı resmi olarak) bir dereceye kadar kullanacaktır.
  2. Genel güvenilirliğiniz ve işleri ne kadar hızlı ilerlettiğiniz ve bitirdiğiniz çoğu zaman, kodlama kabiliyetinizden ayrı olarak çok önemli bir faktördür.
  3. İletişim. Çok şey yapıyorsanız ve iyi yapıyorsanız yöneticinizin bunu bilmesi gerekir! (Tabii ki palavra atmaktan kaçının). "Yöneticinizi yönetmeyi" öğrenin ve pasif olmayın. Patronunuzun nasıl çalıştığını bilmesine yardımcı olun.

2

Yöneticiler kodlayıcı kendileridir ve bu nedenle basit bir gözlemle kodlayıcının iyi olup olmadığını anlayabilirler.

Yöneticileriniz kodlayıcı değilse (ve yazılım işindesiniz), mahvolursunuz.


2

Bir yönetici olarak, programcılarımı değerlendirirken baktıklarımdan bazıları:

  • Akran geri bildirimi. Ekibimdeki programcılardan ve diğer takımlardan programcılardan bana halkım hakkında geri bildirim göndermelerini istedim.

  • Akran saygı . Programcılarım bir problemi çözdüklerinde çözemedikleri, “hadi gidip tavsiye için soralım” derler.

  • İşleri halleder . "X istiyorum" diyorum ve ertesi gün, X bitti.

  • Her şeyi akıllı yapar . "X'i istiyorum" diyorum ve ertesi gün sadece X yapılmakla kalmadı, tüm X benzeri şeyler çözüldü ve daha fazla ilgiye gerek yok.

  • Beni giderir . "X'i istiyorum" diyorum ve programcı "X haklı değil, Y yapmalıyız ve işte neden" diyor.

Dışarıda pek çok iyi yönetici yok (ilgili soruya bakın: progammers bir insanın iyi mi yoksa kötü bir menajer olduğunu nasıl bilir?). İnsanları iyi idare etmek zordur ve çok zaman ve sıkı çalışma gerektirir. 5 kişiyi yönettiğimde, programlama için neredeyse hiç zamanım olmadı. 8+ kişiyi yönetirken, artık onları hak ettikleri kadar iyi idare edemedim.


1

Sanırım, sorunuzun öncülünün, yöneticilerin gerçekten koda bakmadıklarını iddia etmelerinde bir kusur olduğunu düşünüyorum. Yöneticilerimin meslektaş mühendis olduğu birçok durumda çalıştım ve kod incelemelerine aktif olarak katıldım.

Bununla birlikte, teknik olmayan bir kişinin yazılım mühendislerinden sorumlu olduğu birçok durum vardır ve kendi bilgi ve deneyimlerine güvenemezler.

Bu durumlarda, sorumlu yöneticiler mühendisin meslektaşlarını tavsiye isteyeceklerdir. Mühendisin iletişim kurduğu kuruluşta teknik sorumluluğu bulunmayan kişilere, artan sorumlulukla uyumlu iyi insan becerilerine sahip olup olmadığını görmek için soracaklardır.

Sorumsuz olanlar sadece "bağırsak" tepkileriyle devam edecekler, genellikle desteklenmeyen bir tür "ölçüm" kullanıyorlar.

Bu bir saçmalık, ama başka bir yerde daha iyi bir şey için her zaman istifa ve umut edebilirsin.


1

Çalıştığım yerde, çalışan değerlendirmeleri gerçekleştiğinde, yöneticiler çalışanla düzenli olarak etkileşimde bulunanlara gayri resmi, anonim bir sorgulayıcı gönderir; Hem diğer geliştiriciler hem de müşteriler. Bu, diğer geliştiricilere, yöneticilerin aksi takdirde göz ardı edebileceği bir kodlayıcı olarak performans hakkında girdi verme fırsatı sunar.


1

Yönetici ölçülebilir olanlara bakmak zorundadır. İşin hangi yönleri, işin yapılması, işin kalitesi açısından ölçülebilir. Çok fazla hata üretmemeniz veya son kullanıcının yapması gerekeni yapmasına izin vermediğiniz sürece, kaliteli bir iş yapıp yapmadığınızı bilemeyebilirler.

İşiniz yöneticiye masraf olarak mal olur, bu nedenle istihdama devam etmek için finansal olarak karlı olmalısınız.


1

Bunu yapmanın en iyi yolu olduğunu söylemiyorum, ama bunu müşteri memnuniyetine dayandırırlar. Uygulamayı beğenirlerse, böcek miktarını kabul edin ve zamanında yeni özellikler eklediğinizi hissediyorsanız, geliştiricileriniz gerçekten bu kadar kötü olabilir mi?

Tabii ki yapabilirlerdi. Kodlama yoluyla zor kullanabiliyorlar çünkü iki işi yapan 10 kişiniz var. Veya uygulamanızı çok ucuza sattığınız için müşteriler memnun.

Bu yaklaşımla ilgili bir diğer sorun, teknik olmayan yöneticinin müşteri geri bildirimlerini almadan önce bir uygulamanın bitmesini beklemeniz gerektiğidir. Sadece bir yıl boyunca bir uygulama oluşturun ve hiç kimse beğenmedi.

İnsanlara 'Sadece çalışmasını sağlamak' için söylemeye güvenirseniz hayat daha kolay olacaktır. İnsanları doğru sürece anladığınızda ve bunlara bağlı kaldığınızda, birçok sorunu ortadan kaldırırsınız. Gerçekçi olan zorlu tarihlere sahip olabilirsiniz. Her aptal gerçekçi olmayan talepler ortaya çıkarabilir ve yetenekli insanları kaybetme riskini alabilir.


1

Teknik bir ekipte çoğumuzun kimin sallanıp kimin berbat olduğunu bildiğini düşünüyorum. Muazzam ciroya sahip olmadığınız sürece, krema en yükseğe çıkar ve ölü ağırlık düşer. Ufak tefek devler her zaman bir tür derttedirler - kodlarını kontrol etmeden önce test etmeyi unuturlar, böylelikle kırılırlar, bir şeyi yapıp yapmadıklarında daima mazeretleri olurlar.


1

Birinin iyi bir programlayıcı olup olmadığını bilmediklerini düşünüyorum, çünkü bunu yapabilme becerilerine sahip olmadıkları için beucase. Birinin iyi bir geliştirici olup olmadığını kontrol ederler . Programlama bir gelişme faaliyetidir, ancak gelişmenin başka birçok özelliği vardır. Bu nedenle, zamanında olup olmadığınızı, tahminlerinizin iyi olup olmadığını, hata takip sisteminizde, yumuşak becerilerinizi, bağlılığınızı, iletişiminizi vb. Yaptığınız şeyler üzerinde birçok kusur olup olmadığını kontrol ederler.

Bazıları Gurus'un bazen unuttuğu ve sinirlendiği şey, işimizin sadece programlama değil aynı zamanda çok önemli olan yapacak çok şeyimiz var. Yöneticiniz kodunuzun nasıl göründüğüne bakmayacak olsa da (ona tamamen önemsiz olduğu için), takım oyuncusu, sorumlu, saygılı ve genel olarak yüksek kaliteli bir iş yapıp yapmadığınızı kontrol edecektir .

Bazen kodun abartıldığını düşünüyorum.


0

Geliştiriciler için hiyerarşi düzeni hakkında genel bir anlayışa sahip olmayan çok az insanın (yalnız yöneticiler) olduğunu düşünüyorum. Herkes onların birinci sınıf bir geliştirici olduğunu düşünüyor, kötü geliştiricilerin kim olduğunu bilmeyen tek kişi, bu kötü geliştiricilerin kendileri. Her neyse, etrafta dolaşıp birileriyle birlikte çalıştıkları geliştiricileri sıralamasını istemeniz durumunda, çoğu insan için kolay bir iş olacağını düşünüyorum. Yani kimin çok iyi performans gösterdiğini ve kimin ortalama ya da kötü performans gösterdiğini belirleyen bir sihir yok ... Geliştiricilerin ve yöneticilerin aynı fikirde olmayacağı tek şey bu satış görevlileri tipleriyle, ne dediklerini bildikleri gibi yüksek sesle olanlar. hakkında ama gerçekten yapma. Çoğu yönetici onlar tarafından boboze edilir, ancak geliştiriciler değildir.

Bundan sonra, sıralamanızı belirleyen yöneticinizin önyargılarıdır. Bazılarına göre, kodlama giriş seviyesi bir görevdir, bu nedenle kodlama konusunda mükemmel olabilirken, aradığınız promosyonu elde etmeyecektir. Diğerleri tasarım veya mimari yönlere en önemlisi olarak bakarken. Ve diğerleri ihtiyaçların tanımlanması ve toplanmasının (yani iş analizi) en önemli olduğuna inanıyor. Yöneticiniz için neyin önemli olduğunu bilmek istiyorsanız ve en iyi sanatçı sıralamasını almadıysanız, en iyi sanatçı sıralamasını almak için ne yapmam gerekir? Bu cevapta onlar da neyin önemli olduğunu öğreneceksiniz ve o zaman bu önemli alanlarda üstün olduğunuzdan emin olmak size kalmış.

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.