Yeni işe alınan bir çalışan olarak değişiklikler nasıl önerilebilir? [kapalı]

Geçenlerde büyük bir şirkette işe alındım (binlerce kişi, büyüklüğü hakkında bir fikir vermek için). Beni titizliğimden dolayı işe aldıklarını ve gençliğime rağmen (25 yaşıma rağmen) C / C ++ programcısı olarak deneyimlendiğimi söylediler.

Artık içeri girdiğimde, tüm sistemin eski olduğunu ve çoğu zaman eski teknolojileri kullandığını görebiliyorum. Adlandırma kuralı yok (dosyalar, işlevler, değişkenler, ...) Sürüm Denetimi kullanmıyorlar, istisnalar veya polimorfizm kullanmıyorlar ve neredeyse herkes tutkusunu kaybetmiş gibi görünüyor (bazıları sadece 30 yaşında. ).

Bazı değişiklikler önermek isterim ama "uyum sağlamak istemediği için her şeyi değiştirmek isteyen yeni adam" olmak istemiyorum. "Uyum sağlamaya" çalıştım, ama aslında, kullanmak zorunda kaldığımız fakir aletlerden dolayı, bir öğleden sonra ne yapacağımı yapmak bir haftamı alıyor. Meslektaşlarımın çoğu, günümüzde insanların kullandığı yeni "şeylere" ve tekniklere asla bakmıyor. Daha yeni vazgeçtikleri gibi. Durum gerçekten sinir bozucu.

Hiç benzer bir durumda oldunuz mu ve eğer öyleyse, bana hangi önerileri verirdiniz? Buradaki kara koyun olmadan işleri değiştirmenin ince bir yolu var mı? Yoksa tutku ve enerjimi de bırakmalı mıyım?

Teşekkür ederim.

Güncellemeler

Değerli tavsiyelerinizi takiben, değişiklikler önerebildim ve şimdi Subversion: D oluşturmak ve yerleştirmek zorunda olan ekibin sorumlusuyum. Hepinize teşekkürler!

6 ay sonra

İstifa ettim ve çok daha ilginç bir ortam buldum, çok daha iyi bir ödeme ve daha ilginç zorluklarla. Hiçbir şey için geri dönmem.

Ben de 5 senedir çalıştığım önceki şirketimde benzer bir durumdaydım. 2004 yılında katıldığımda, onlar:

• hala veritabanları için Microsoft Access kullanıyor (iş için kritik olanlar bile)
• geliştirme için Visual Basic 6 veya Access / Excel VBA kullanma
• geliştirme kaynağını şirket içi yerine kullanmak yerine pek çok üçüncü taraf kullanmak (işletme yöneticileri kendi geliştirme projelerine öncülük etmiş ve zamanın% 90'ı BT bilgisi olmadan ihaleye çıkmıştır)
• gasp versiyon kontrolü yok.

Geçen yıl ayrıldığımda şirket:

• yalnızca .NET ve C # kullanarak
• tüm Access gelişimini yasakladı
• sürüm kontrolü için SVN kullanımı
• 2 tane etli SQL Server kutusu vardı ve mevcut Access veritabanlarını SQL'e taşıyorlardı
• Tüm gelişim şirket içi ekipler aracılığıyla gerçekleştirildi ve yalnızca kaynak sınırlı olduğunda ihaleye çıktı.

O zamanlar 21 yaşını doldurmamıştım ve geliştirme takımındaki bir sonraki genç 30 yaşındaydı. Ben kendim yapmadım. BT yöneticisi aynı anda şirkete katıldı ve tüm gelişmeleri BT aracılığıyla sağlamak istedi.

SVN ilk başarımdı. Bölüm müdürümle bir toplantı yaptım ve kodların canlı yayınlanmasına veya sorunlara yol açan değişikliklerin yaşandığına dikkat çektim ve hesap verebilirliğin olmadığı gerçeğini vurguladım - hiç kimseyi suçlayamadı - ve bundan sonra dinlemeye başladı.

Daha sonra takıma bir sunum hazırladım ve sürüm kontrolü kavramını açıkladım ve SVN'nin geliştiricilere yardımcı olabileceği birkaç durumu ortaya koydum. Küçükler suya bir ördek gibi götürdüler, yaşlılar o kadar da değil ama denediler ve onu kullananlardan şikayet etmediler.

Diğer bir büyük başarı da şirket içi eksiksiz bir sistem getirmekti - Şirketi lisanslamada yılda 120.000 sterline kazandıran bir projeye öncülük ettim. Boş zamanlarımın yaklaşık 2 ayını yeni bir sistem yazmak için harcadım ve bunu BT yöneticisine sundum ve maliyet tasarrufunu açıkladım. Daha sonra işletime sunmama izin verdi ve sisteme ne sevdilerse uygulayabileceğimizi açıkladı - artık "kullanıma hazır" sistemlerle sınırlı kalmadı.

4 hafta sonra sistemim 10 noktada pilottaydı ve 6 ay sonra yayına girdi. Bir yıl sonra, üçüncü taraf sözleşmesini iptal ettiler, tüm izlerini ağdan çıkardılar ve şirket içi sistemimize büyük bir geliştirme gereksinimi için bize geldiler.

Sana tavsiyem:

• Şirketi önemsiyorsan, çıkar. Diğerleri yaklaşımınızdan hoşlanmıyorsa, sizinle birlikte ele almalarına izin verin - bu tamamen uzlaşma ile ilgili.
• Konuştuğunuz kişiye önerileri uyarlama - yöneticiler nasıl yapabildiklerini duymayı severler a) para biriktirir, b) yanlış şeyler yaptıklarında insanları doğru şekilde suçlarlar, ancak geliştiriciler nasıl yaptıklarını duymayı severler a) zaman kazanır, b) uydurur kendileri için, örneğin
• Değişim konusunda tutkuluysanız (ki bu sizin gibi geliyor) o zaman insanlara coşkunuzu gösterin ve coşkulu olmadıklarında daha az boğulmadılar
• Değişiklik yapmaktan bahsetme. Bunları yapmak. Harika bir işi daha deneyimli insanlardan daha kısa sürede çalkalamaya başladığınızda, insanlar “neden?” Diye sormaya başlayacaklar.

Beni titizliğimden dolayı işe aldıklarını ve gençliğime rağmen (25 yaşıma rağmen) C / C ++ programcısı olarak deneyimlendiğimi söylediler.

Daha muhtemel çünkü sen daha ucuzsun.

Hiç benzer bir durumda bulundun mu?

Evet.

bana hangi tavsiyeleri verirsiniz

Ayrılmak.

Burada kara koyun olmadan işleri değiştirmenin ince bir yolu var mı?

Söz konusu olabilir. Değişiklikleri tanıtın ve herkes için işleri nasıl geliştirdiklerini gösterin. Bunu birkaç kez yaptıktan sonra, kaybedilmemiş olanlardan takdir alabilirsiniz.

Yoksa tutku ve enerjimi de bırakmalı mıyım?

Olmaz. Gençsin ve fırsatlardan tam olarak yararlanmak zorundasın. Yılları "bir yere" harcamayın. Bu pozisyona bakın ve kariyerinizi daha da ilerletmek için size değerli bir deneyim sunup sunmayacağını anlayın. Fırsatları görürseniz, onları keşfedin. Hiçbiri yoksa ve sadece "bir iş" ise, çıkın. Uygulama gösteriyor ki, tutkularını kaybedenler (veya hiç sahip olmadılar), onu yeniden elde edemezler. Tutkulu insanlardan oluşan bir ekip arayın ve onlara katılın.

Örnek olarak kurşun . Zaman zaman aşamalı olarak küçük değişiklikler. Bir meslektaşı devirmek ve onlara bir şey demo. Almazlarsa boşver, başka bir zaman tekrar dene.

Zaman alacak. İnsanları kendi rahat bölgelerinden çok hızlı bir şekilde çekmeyin.

Üzücü ama bu yüzden buradasın ve onlar değil.

Örneğin. Sürüm kontrolünü yerel olarak ayarlayın ve nasıl yardımcı olabileceğini gösterin. Sonra onlara, sizi destekleyebilecek bazı kaynaklar (basit okumalar) verin.

Araçlar hakkında başka bir şey . Bazen kendi paranı daha iyi araçlar satın alarak harcaman gerekir. Bunun 'bitmiş şey' olmadığını biliyorum, ancak diğer esnaflarla konuştuğumda, birçok “gerçek” mühendis buluyorum ve işlerini daha iyi yapmak için kendi araçlarını satın alıyorlar. Ben her zaman bunu yaptım, kendimi yetenek atrofisinden kurtardığımı görebiliyorum.

Ben yaşlı bir adamım (51) ve bu aynı problemi sahip olduğum her işte yaşadım. Belki de sadece odadaki en zeki adam olmaktan gelir! :-) Cidden, yine de, nasıl doğru yapılacağını ve ne yaptığını bildiğiniz zaman, sık sık şöyle düşünürsünüz, "Hey, herkese bu yeni ve geliştirilmiş tekniği göstereceğim ve hepsi etkilenecek ve atlamak isteyeceklerdir. onu kullanmak için. " Ancak gerçek hayatta, zamanın% 90'ında, insanlara daha iyi bir yol gösterirsiniz ve neden baştan beri yaptıklarının daha iyi olduğu için uzun bir bahane listesi hazırladılar. Sebeplerinin geçerli olmadığını kanıtladığınızda, yeni, hatta lamer sebepler ortaya çıkar. Ben birçok kez yaşadım

Gerçekten bir dahi olsan bile, bunu kanıtlayana kadar kimsenin bir dahi olmadığını bilmediğini kabul etmek zorundasın. Bir arkadaşımla 10 yıl geçirdikten sonra yeni bir işe başlayan bir arkadaşım olan Kris'i hatırlatıyorum. Yeni işe başladıktan kısa bir süre sonra, bazı teknik sorunları tartıştıkları bir toplantıdaydı ve önerilen çözümünü sunmaya başladı. Sonra başka biri araya girdi ve "Evet, teşekkürler. Bob, ne düşünüyorsun?" Dedi. İlk başta sinirlendi: Doğru cevabı biliyordu ama kimse umursamadı! Bunun yerine, ondan çok daha azını bilen birinin görüşü ile gittiler. Fakat sonra fark etti ki, hey, eski işimde, neden bahsettiğini bilen biri olarak ün saldım, bu yüzden konuştuğumda insanlar dinledi. Burada, henüz bir ünüm yok, bu yüzden kimse ne düşündüğümü umursamıyor.

2 yıldır şu anki işimdeyim ve sadece son birkaç ay içerisinde, fikrimin gerçek ağırlığı olmaya başladı. Sabırlı olmalısın.

Kapak tarafında, yeni insanlar çoğu zaman gerçekten pratik olmayan iyileştirmeler için milyonlarca öneride bulunuyorlar, çünkü organizasyon hakkında henüz yeterince bilgi sahibi değiller ve bu yüzden işlerin neden olduğu gibi yapıldığını bilmiyorlar. Bazen insanlar 20 yıl boyunca aynı şeyi yapmaya devam ederler çünkü bu hep böyle yapılır ve hiç kimse daha iyi bir yol aramayı düşünmezdi; ama bazen insanlar 20 yıl boyunca aynı şeyi yapmaya devam ederler çünkü deneyimler bunu yapmanın iyi bir yol olduğunu ve her seferinde farklı bir şey denediğinde bunun bir felaket olduğunu göstermiştir. Bu yüzden bütün bu insanların aptal olduğu sonucuna varmak için çok hızlı olmayın. Yeni önerinizi ortaya koymadan önce neden bunu eski yöntemle yaptıklarını öğrenin. Ben hayatımda birçok kez yaşadım.

Şirketi geliştirmek isteyen müttefikleri bulun.

Şimdi kurtulmak ve çürümeye bırakmak için söylenecek bir şey var. Ancak, sürüm kontrolünü ve diğer iyileştirmeleri başarılı bir şekilde savunursanız özgeçmişinizde harika görünecek.

Gelecekteki röportajlarınız sırasında Joel Test'i kullanın . Unutmayın, şirketle de röportaj yapıyorsunuz.

İlk tavsiyem, çok yakında çok fazla değişiklik yapmaya çalışma. Öncelikle işleri halledebilecek iyi bir güvenilir geliştirici olarak ün kazanın. Şu anda acemi olarak, önerdiğiniz her şey şüpheli; Henüz seni bilmiyorlar ve sana saygı duyuyorlar. Bu saygıyı ilk adımınız olarak alın. O zaman değişiklik yapmaya başlamanın zamanı geldi.

Zemini dikkatlice seç. Yeni teknolojilerle değil sürüm kontrolü ile başlayın. Çünkü gerçekten en önemli değişiklik bu. Bunu sadece kodunuzla bile yapabilirsiniz ve daha sonra neyin değiştiğini bulmak için önceki bir sürüme dönmeniz veya copmpare yapmanız gerektiğinden, insanların günlük konuşmada ne kadar kolay olduğunu bildiğinizden emin olun.

Daha güncel bilgilerinizi, parlayan kişi olmak için kullanın ve ardından insanlar bunu nasıl yaptığınızı sormaya başlar. Adet işyerine ilk girdiğinde, bir devlet denetim kurumu için çalıştım. Yaşlıların hepsi kendi bilgisayarlarına (sekreterler için işe yaradığı için) sahip olmalarına karşı çok büyüktü. Küçükler ilk bilgisayarların hepsini aldılar ve yaşlıların Lotus 1-2-3 ve Harvard Graphics ile yapamayacağı şeyleri yapmaya başladılar ve aniden yaşlı insanlar ilgilendi çünkü genç çocuklar üst düzey yöneticilerin dikkatini çekmeye başladılar.

Bir örgütsel kültürde değişim teknik bir mesele değil, politik bir meseledir. Ofis politikalarını yönetme konusunda biraz okuma yapın. Üst düzeyde politik desteğe ihtiyacınız olacak.

Şu anki işimde de benzer bir durumla karşılaştım. Genellikle 15 yaşından beri burada çalışan mühendislerden oluşan bir ekipte çalışmak için doğrudan okuldan işe alındım. Değişiklik yapmak kolay değildi (hala yapılması gereken bazı şeyleri zorluyorum), ancak mümkün.

Örneğin, ekibim 16 bitlik DOS test programını kullanıyor, güncelliyor ve kullanıyordu. Yardımcı program güncellenmesi çok büyük bir acıydı, çünkü uygulama 16 bitlik bağlayıcının sınırlarını koyduysa, kod eklerseniz, sığması için başka bir şeyi kaldırmanız gerektiğine itti. Neden 16-bit kodda bu kadar zaman ve enerji harcıyoruz diye sorduğumuzda, yanıtları "DOS'ta çalıştırılması gerektiğinden, önyüklenebilir bir flash sürücüden çalıştırmamız gerekiyor" idi. Onları programı 32 bit Linux'a aktarmaya ikna etmeye çalıştım, ancak yönetim bunu yapmak için zaman harcamak istemiyordu (zaten olduğu gibi yapacak çok işimiz vardı). Bu yüzden, devam ettim ve yardımcı programımı aşağı zamanımda taşıdım (burada 15 dakika öğle yemeğinde, hafta sonlarında veya başka bir kodun derlenmesini beklerken). Birkaç ay boyunca Yardımcı programı tamamen taşıdım, orijinal 16 bit uygulamasının kaldıramayacağı her türlü şeyi geliştirdim ve bir Linux flash sürücüden başlattım. İnsanlar kullanmaya başladığımda farkettiler ve işleri nasıl daha hızlı halledebileceğimi ve yardımcı programımın nasıl daha iyi hata ayıklama çıktıları ürettiği konusunda yorum yapıyorlardı. Çok yakında, yönetim bunu duydu. Faydaları gördükten sonra (ve en önemlisi, işin zaten yapıldığını), artık fikre karşı değildiler.

Bu hikayeden öğrendiğim ders şudur: Bir şeyi geliştirebileceğinizi düşünüyorsanız, yöneticinizle bunun hakkında konuşun. Kaynakları harcamak istemiyorlarsa, kendi başınıza yapın ve fikrinizin geçerli ve yararlı olduğunu ispatlayın . Birinin önünüzde gördüğünüz ve bariz değeri olan bir şeyden daha çok önerdiği fikrine hayır demek çok daha kolaydır.

Ekibiniz / yöneticiniz fikrinizi uyguladıktan ve faydalarını görmeye başladığında, gelecekte fikirlerinizi dinlemesi çok daha olası olacaktır. Test aracımdan elde ettiğim "sokak kredisini" tekrar kullandım, ekibimi mevcut, eski sürüm kontrol sistemimizi (utançtan kaçınmak için anonim kalacak) ve Subversion'a geçmemiz gerektiğine ikna etmek için gerekli olduğuna ikna etmek için kullandım. Yönetimin onaylayacağından emin olmak için kurulum / göç çabalarına liderlik etmeye gönüllü oldum.

"Her seferinde bir adım" gibi bir şey. Muhtemelen değiştirmek istediğiniz tonlarca şey vardır, ancak başlamak için küçük bir şey seçin. Fikirlerinizin kalitesini ekibinizin ve yöneticinizin 'hayır' demeyeceği şekilde gösterin. Stackoverflow hesabınız gibi, ne kadar iyi fikirleriniz olursa, saygınlığınız o kadar iyi olacak ve fikirleriniz için kabul edilmesi o kadar kolay olacaktır.

Yerel olarak sahip olmak istediğiniz araçları kesinlikle kullanmaya başlayın (nerede yapabilirsin - bazı şirketler aynı zamanda tuhaf bir yumrukla kutunuza ne yükleyebileceğinizi kontrol ediyor gibi görünmektedir). Favori versiyon kontrol sisteminizi kurun ve kullanmaya başlayın. Dokunduğunuz herhangi bir kodda, özellikle de yeni bir kod yazarken, kodu temizleyen küçük değişiklikler yapın. Eğer titizlik ve deneyiminiz için sizi işe aldılarsa, bu zaten size saygı duydukları anlamına gelir.

Geçenlerde Hiring Ren ve Stimpy'yi okudum ve Stimpy örneğinin çok zor olduğunu gördüm . Onun öncülüğünü izlerseniz, iş arkadaşlarınızdan her türlü bakış açısını isteyip istemediğinizi soracaksınız. Herhangi bir boş zamanınızı, iyileştirme yapmanın hayallerini kurmak için harcayacağınız zaman harcayacaksınız. Şirket işinizi değerli olarak görürse, paha biçilmez olacaksınız. Olmazlarsa, muhtemelen iş arıyor olmak istersiniz.

Birçok insan, her seferinde küçük bir şeye odaklanma önerileriyle cevap verdi ve birçoğu sürüm kontrolünü önerdi. Bir adım daha ileri gideceğim: masaüstü makinenizde depolar oluşturun ve bu depolardan çalışın. Şirketin kullandığı ana depodan bunları düzenli olarak güncelleyin. Birisi ustaya zarar verdiği için (eğer değilse) bir kriz olduğunda, onlara kişisel deponuzdan yeni bir kopyasını kesebileceğinizi söyleyin.

Ancak, hiçbir koşulda şahsen sahip olduğunuz veya evinize aldığınız bir makineye şirket kodu koymayın . Çünkü o zaman bir kahraman olmak yerine, masanın yanlış tarafında bir avukattan (en iyi ihtimalle) ya da kanun uygulayıcıdan (en kötüsünde) olduğunuzu öğrenebilirsiniz.

Başka bir küçük geliştiriciden geliyorsanız ... harika insan becerileriniz var mı? Mükemmel bir kişisel kısıtlama anlayışına ve bir fikrin ne zaman ve ne zaman uygun olacağına ve bu fikrin en iyi nasıl satılacağına dair bir anlayışa sahip misiniz? Yapsanız bile, diğer insanlara işinizi nasıl yaptığınızı kanıtlamadan nasıl yapacağınızı söylediğiniz için "o adam" olabilirsiniz.

Küçük bir geliştirici olarak güvenilirliğimi şu şekilde geliştiriyorum: Kink / kludge / time waster. Sonra başkalarını rahatsız etmeden otomatikleştirerek (toplu iş dosyaları, powershell scriptleri, basit program, yeni ücretsiz, hafta sonu ne olursa olsun) düzeltebilirim. Bunu devam eden teknik öz-eğitimimin bir parçası haline getirdiğimden emin oluyorum, böylece “kendime yeni bir şey öğretmek ve şirkete yardım etmek için fazladan saatler koymak” diyebilirim.

Düzeltmem özellikle şıksa, paylaşıyorum ve "Hey beyler, bu harika aracı yaptım, XY ve Z'yi otomatikleştiriyor ve diğerlerini hızlı bir şekilde yapıyor." Üzerinde adın kalsın. Tekrar et. Seviyeniz için yüksek bir performans sergileyecekseniz ve birkaç ay içinde güvenilirlik sorunu çözüldü ve fikrinizin neden iyi olduğunu ve problemlerini nasıl çözebileceğini açıklamaya hazırsanız, üstünüzdeki insanlar önerilerinize daha açık olacaktır.

Son zamanlarda, üst düzey yönetime kabul edilen yeni fikirler önerebildim, çünkü çoğunlukla mantığımı açıklamak, geri bildirimlerini dinlemek ve geçmiş çalışmalarımın güvenilirliğine sahip olmak için zaman harcadım.

EK: Yöneticiniz davranışınızı sorguluyorsa ... performansınızın en azından% 25’te kaldığını hissetmediği sürece bu işleri yapmayın, IE her türlü şeyi denemeye başlamadan önce patronunuzun sizinle birlikte mutlu olduğundan emin olun seni% üst seviyesine yükselten zeki düzeltmelerden biri yoksa zamanını boşa harcayacağını düşünür. Olumlu performans geribildirimi sağlarken yeni araçlar ve çözümler ortaya atıyorsanız, ancak hala mikro yönetme konusunda ısrar ediyor, bu konunun kapsamı dışında bir sorunla karşılaşabilirsiniz.

Uyum.

Söylediğin gibi, kara koyun olmak istemiyorsun. Ancak, (kendim gibi) bazı yararlı değişiklikler eklemek istediğiniz için:

Arka planda değer katın.

İnsanların kodunu svn / hg / git olarak kontrol etmek için cronjobs kurun. Kendi araçlarınızı kendi zamanınızda yapın, bu da geliştirme çabalarını gözle görülür biçimde iyileştirir. Özellikle, yaşlılara kendi kabininizde gösterebileceğiniz şirkete iyileştirmeler yapmak istiyorsunuz . Ve işte neden:

Vay faktörü

"Hey Alice, Bob'un yapıyı nasıl kırdığını biliyor musunuz? Düzenlemesini geri alabilirim ve yapı yeniden çalışır". Ve büyüklerin kutsal şeyler dediğinde, belki de yeni uygulamalarını zorlayacakları veya en azından cesaretlendirecekleri tutkuları uyandıracaksın.

İşte benim tavsiyem.

Benzer bir durumdaydım, önce söylemeliyim ki, şirketim 6 geliştirici hakkında oldukça küçük, yeni teknolojiyi, yeni araçları ve işimi kolaylaştıracak ve daha kaliteli yazılımlar üretecek her şeyi kullanmayı seven bir tür programcıyım. .

Başladığımda, VS2008 bir süredir piyasaya çıktığında Visual Studio 2005 kullanıyorduk, ancak patronumun para kazanmasını sağlamak için tüm geliştiricilerin kolaylaşması yoktu. "Bunu yapabilseydik güzel olurdu", ama patronuma getirmeden önce, diğer geliştiricilerin fikir üzerinde iyi olacağından emin olacaktım, çünkü onu kullanan ve içinde bir grup insan bulunanlardı. lehine bir kişinin kararına daha az benzeyecek.

Sanırım sadece fikrini patronuna atmak yerine, muhtemel değişiklikleri yavaşça gündeme getir, çünkü şirketi daha iyi bir şekilde değiştirecek fikirler önerip önermediğini düşünürüm, işini umursadığını ve planladığını gösterir. orada bir ev yapmak üzerine.

Bu aynı zamanda içinde bulunduğunuz çalışma ortamına ve patronunuzun kişiliğine de bağlı olacaktır, eğer geri yatırılıp size aileniz gibi davranırlar ve tavsiye alırlarsa, önerin, ama size bir sayı gibi davranırlarsa, çok dikkatli olurdum. sen yaklaş.

Bir ömür boyu bir fırsat olabilir - bir şirketin 25'te çalışma şeklini değiştirmek. Yine de direnir ve düşmanlık gösterirlerse, sizin için uygun bir yer değildir.

Unutmayın, görüşmeniz iki yönlü bir süreçti. Ne kadar arkaik ve değişime karşı dirençli oldukları konusunda bir fikriniz olabilir.

Ps, ben de 25 yaşındayım ve nasıl hissettiğini biliyorum. Muhtemelen öğrenmek ve yeni şeyler denemek için iş arkadaşlarınızdan çok daha heveslisiniz. Her neyse, getirdiğim bu .NET4 çalışmasına geri dönmeliyim;)

Joel Spolsky tarafından sadece homurdandığın zaman yapılması gerekenleri oku .

... bazen yönetici fiat tarafından organizasyonunuzda değişiklik yaratma gücünüz olmaz. Açıkçası, sadece totem direğinin dibinde büyük bir programcıysanız, insanlara programları veya hata veritabanlarını oluşturmaya başlamalarını emredemezsiniz. Ve aslında bir menajer olsanız bile, muhtemelen geliştiricileri yönetmenin kedi sürüleri gibi olduğunu, sadece eğlenceli olmadığını keşfettiniz. Sadece "öyle yap" demek, bunu yapmaz.

Joel Testinde düşük puan alan bir organizasyonda çalışırken sinir bozucu olabilir . Kodunuz ne kadar iyi olursa olsun, iş arkadaşlarınız o proje ile ilişkilendirildiğiniz kadar kötü bir kod yazıyor. Veya yönetim hangi kodun yazılacağına dair kötü kararlar alıyor, bu nedenle çocuklar için bir emeklilik planlama oyununun AS / 400 versiyonunda hata ayıklama yeteneğinizi harcamak zorundasınız.

... kötü bir takımda hayatla uğraşmak çıldırtıcı olabilir. Ama takımını en alttan geliştirmeye yönelik stratejiler var ve bunlardan birkaçını paylaşmak istiyorum.

Yönetimi ile çalışmak; "haydut" etme. Süreç içinde çalışın ve işleri “insanlar svn uygulamak bize bir sunucuda yer alacak, kurulum için iki gün sürecek ve desteklememiz gerekecek gibi” gibi şeyleri anlayacaklar. "Bu bize çok para kazandırabilir."

Bırakmak, vazgeçmek. Dışarıda bir sürü iş var. Seni işe alan bazı rasgele şirketleri tamir etmek senin işin değil. Oldukları gibi seviyorlar, yoksa yeni bir CTO falan kiralarlardı.