Hata çözmede daha hızlı olmanın bir yolu var mı? Patronumdan bir uyarı aldım [kapatıldı]

Patronum tarafından Pazartesi günleri olumsuz bir performans incelemesi alacağıma söylenmişti. Neden ben bu kadar yavaş olduğum ve neden hata düzeltme oranımın bu kadar düşük olduğu hakkında konuşmak istiyor.

Programlamayı ve problem çözmeyi seviyorum ama işimi gerçekten çok zor buluyorum.

Aslında yaklaşık 10 yıldır programcı oldum. Ama bu benim çok iş parçacıklı ilk gömülü linux işim - 2 senedir buradayım ve hala mücadele ettiğim herkese açık. Ve sanırım işimin başında sahip olduğum ateşin çoğunu kaybettim, o kadar moralsizleştim ve kendimi çok marjinal hissediyorum.

Hiç kimse benzer bir durumda oldu mu ve hata düzeltme oranınızı artırma konusunda nasıl gidiyorsunuz?

Güncelleme: İnceleme aldım. 3 aylık bir çalışan geliştirme programına (Dunk tarafından belirtilen türde) girdim. Bunu tersine çevirebileceğimden emin değilim. Fakat devam etmem gerekse bile, bu deneyimden çok şey öğrendim.

Başka bir güncelleme

İlk incelemeden bu yana yaklaşık 6 hafta geçti. Aynı durumla karşı karşıya kalan herkese tavsiyem, eleştirilere kapılacak ve hatalarından ders almaya yetecek kadar mütevazı olmak. Ve aptal görünmekten korkmamak. Bir sürü soru sorun. İnsanların öğrenmeye çalıştığınızı bilmelerini ve anlayana kadar sormaya devam etmelerini sağlayın. Fakat işe yaramaması için hazırlıklı olun. Bir kod portföyü oluşturuyorum ... ve en iyi vuruşumu yapıyorum.

Yine başka bir güncelleme

Bunu buraya koymakta tereddüt ediyorum, çünkü gelecekteki işverenleri yığın akışı profilime yönlendiremeyeceğimden endişeleniyorum ... Ama yine de, bu soruyu okuyan birinin ilgisini çekebilir, ancak gerçekte birkaç hafta önce iş. İhtiyacım olan tüm yetenekleri tazelemenin tam ortasındayım - burada verilen tavsiyelerden çok şey aldım.

Birçok cevap patronunuzun yöntemlerini / taktiklerini / metriklerini / vb. Sorguladı. Ama bu noktanın yanı sıra .... Belki yavaşsın. Geliştiricilerin her odası diğerlerinden daha yavaş olan BİR'e sahip olmalı, değil mi? (Bu sadece düz küme teorisi.) Öyleyse, onun olduğunu varsayalım. Cevap, neden yavaşsın? (Açıkçası, nasıl daha hızlı olacağınızla ilgili sorunuzu çözmeden önce cevaplamanız gereken soru budur.)

Her türlü neden olabilir, ama işte dikkate alınması gereken bazı açıklamalar:

1. Sen onlardan daha az akıllısın . Mümkün değil mi? (Çalışmalar biz göstermiştir TÜM olan az popüler , daha az ilginç ve (bizim arkadaşlar daha az zeki) takip edecek.) Böylece belki sadece yavaş beyinli bulunmaktadır. Sonra tekrar, sizin durumunuzda bunun olası olmadığını düşünüyorum. StackOverflow profilinize kısa bir bakış, çok çeşitli konularda akıllı sorular sorma geçmişiniz olduğunu gösterir. Yani açıkça bir düşünürsün ve muhtemelen bu konuda iyi birisin.

2. Çok ince yayılmışsın. Aynı SO profiliniz, sorularınızın son 2 yılda çok geniş bir teknoloji yelpazesini (grafik, web, python, c ++, c, linux, gömülü, iplikler, soketler vb.) Kapsadığını göstermektedir. Şahsen, çok sayıda farklı akışa dalmak (veya istemek) durumunda olduğumda kendimi çok hızlı (veya daha ziyade yavaş ) hızla akarken bulduğumu biliyorum . Belki de burada gerçekten ihtiyacınız olan şey FOCUS'tur . Ve belki de sağlıklı bir önceliklendirme dozu . Daha az önemli olan saksıları arka yakıcıya devredebilir ve ana yemek üzerindeki ısıyı yükseltebilir misiniz?

3. Sen eğlenmiyorsun. Yangın söndüğünde, buhar makinesi yavaşlamaya mahkumdur. Görevinizde moralinizin son zamanlarda ciddi bir darbe aldığını itiraf ettiniz. Ne yazık ki, kendinden destekli negatif harmoniklerin emme girdabına yutuldunuz - köprüleri yok edebilecek bir güç . Çok tanıdık bir spirattır: zor görev -> stres -> cevapsız son tarih -> daha fazla stres -> kötü başa çıkma mekanizması -> daha fazla stres -> erteleme -> daha fazla kaçırılan son tarih - - eleştiri / dedikodu (gerçek veya hayal edilmiş) - > ama daha fazla stres. Resmi aldın. Bu nadiren faydalı bir yere yönlendirir. Beyaz su raftinginde günlerimden bir ders al: Hızlı bir sınıf-4'ün arka tarafındaki dolaşım akımı ile su altına çekildiğinde can yeleğin HAZIRseni yüzeye geri döndürüyorum. En iyi strateji (non-sezgisel rağmen) bulmaktır dibe nehir ve çıkmak riptide arasında. Bu yüzden size tavsiyem: bir miktar zemin , ahbap, (arkadaşlar, kilise, sağlıklı yeni alışkanlıklar, vb.) Bulun ve kendinizi jakuziden çıkarmak için kullanın.

4. Kendi bölgesinde değilsin. Michael Jordan oldukça topal bir beyzbol oyuncusu yaptı. (Tamam, o hala benden daha iyiydi, ama kesinlikle küçük bir leaguer.) Belki de "okuyuculu gömülü linux" sadece senin işin değil. Ancak, Yazılım Geliştirme son derece geniş bir alandır (bildiğiniz gibi; yukarıdaki cf # 2). Şirketiniz başka bir yer bulabilecek kadar geniş mi? Son işimde gömülü bir SW dev olarak işe alındım. (Bu alanda hiçbir deneyimim yoktu, ama onlara "hızlı öğrenen biri olduğumu söyledim." Çabucak bir taş gibi battım. Ama çok çalıştım ve yaptığım sorunları aramaya devam ettim.Onlar için nasıl çözüleceğini bilir. Anlaşılacağı gibi, yavaş yavaş parlayabileceğim ve sonunda hatırı sayılır bir takdir aldığım yeni sorumluluklara geçebildim. Belki de kendini yeniden markalaman gerekiyor.

Mesele şu ki: eğer yavaşsanız, bir sebep var. Ama, hey - sen bir yazılım mühendisisin, ahbap! Kendini hata ayıkla!

Patronunuz doğru olabilir: “düşük performans gösteriyor olabilirsiniz” (bir dakika içinde daha fazlası). Ancak bu, suçlanmanız gereken sadece sizin yetkinlik seviyeniz olmayabilir. Sizin kontrolünüz dışındaki güçlerin strese neden olduğunu, bunun performansınızı olumsuz yönde etkilediğini öne sürmenin kolay olacağını sanmıyorum.

Patronunuzun şimdi bunu ortaya koymasının sebeplerinden birkaçına bakalım:

Kültür ve Politika

Patronunuzun şimdi endişesini dile getirmesini gerektiren kontrolünüzün ötesinde güçler olabilir. Çalıştığınız sistemi anlamak önemlidir. İşiniz patronunuzun iyi görünmesini sağlamaktır. Bunu yapmanın tek yolu, yaşadığı baskıları anlamak.

Kabiliyet

Açıkça söylediği gibi kabiliyetin eşit olmaması mümkündür. İşte bu durumda ne yapardım:

Patronunuzdan performansı nasıl ölçtiği konusunda özel geri bildirim alın . X kişisi kadar böcek kapatmıyor musunuz? Çözmeniz gereken çok sayıda hata var mı? Eğer yalnız çalışıyorsanız, performansınızı ölçenlerin önceden ölçülmüş bir fikre dayanarak değil, onu ölçtüğünden emin olmalısınız.

Performansınız yavaşsa ve gerçek bir boşluğu temel alıyorsa, bu boşluğu tanımlayın ve kapatmak amacıyla patronunuzla birlikte ayrıntılı bir plan yapın.

Bu inceleme aynı zamanda memnun olmadığınız gerçeğini ortaya koymak için iyi bir fırsat. Bu işi sevmediğinizi tespit etmeniz iyi oldu. Ama nedenini çöz. İşinin hangi bölümünü seviyorsun, neler yapmıyorsun? Bu iş senin için değil olabilir.

Bazı çalışma ortamları çalıştırılamaz. Kimsenin hayatta kalamayacağı ortamlar gördüm (başlangıçta olanlar için para biriktirdim) çünkü çok fazla belgelenmemiş ve sorular çok şiddetle cesaret kırılmıştı.

Onlarla tanışmanıza yardımcı olacak beklentiler ve kaynaklar konusunda kendinize karşı dürüst olmanız gerekir. Sorun sen olmayabilirsin.

Siz, kendinize benzer işler yapan, zorluk çekmeyen, fakat 5 yıldan fazla bir deneyime sahip olmayan insanlardan 2 bahsettiğinizi söylüyorsunuz. Onlar tamamen sizi aşan rock yıldızı mı (bu açıdan), yoksa onlar da sizin gibi mi? Belki de sistemi daha basit hale getirdiklerinde daha yeni tanıdılar ... Bu çalışmadan önce 8 yıllık programlama deneyiminden bahsettiniz. Orada nasıl yaptın? Eğer harikaydın, o zaman sana bir şey söylemelisin.

Beni vuran kısım, kendinize giden tüm böceklere ilişkin olarak kendinizi karanlıkta olduğunuzu açıklamanızla ilgili. Kod tabanının beklentileri makul olmayacak kadar geniş ve tarifsiz olabilir.

Yapabildiğiniz kadarıyla başarmanız, bir şeyi doğru yaptığınız ve sizin için bir şeyler yaptığınız anlamına gelir.

Sonuç olarak, bence, kendiniz ve yaptıklarınız hakkında iyi hissetmeniz gerekiyor. Ve eğer bu devam etmek demekse, öyle olsun.

Bir iş hayatını mahvetmek yerine devam etmek daha iyi.

Birincisi, not: bu cevap, çalışanın işten çıkarılmasında işten çıkarılmasının yasadışı olduğu bazı bölgelerde geçerli olabilir. Bahsedilen...

Bu, Yapıcı işten çıkarma davası olabilir ve yasadışıdır.

Buradaki taktik, çalışanın işten ayrılana kadar özveriliğini demoralize etmek ve düşürmektir. Kıdem tazminatı ödememek veya çalışanla yüzleşmek ve onları kovmak zorunda kalmama sorununu çözmek için şirketin para biriktirmesinin bir yoludur.

Neden ben bu kadar yavaş olduğum ve neden hata düzeltme oranımın bu kadar düşük olduğu hakkında konuşmak istiyor.

Bu fay çok belirsiz. Her iki tarafın da diğer tarafın yanlış olduğunu iddia etmesi imkansız. Bir hatayı düzeltmek bir ay sürdü. Ne olmuş yani! Bu, bir ayın gerekli olduğu iddiasını desteklemek için gerçekleri sunmak zorunda kalarak sizi savunma pozisyonunda tutar. Mevcut beceri, deneyim ve bilginizi faktör olarak verin. Bir işveren olarak, çalışanlarının zamanını ve çabalarını yönetmek işverenin görevidir. İşveren, hataların düzeltilmesiyle ilişkili risklerle uğraşan kişi olmalıdır. Çalışan değil. Her zaman hatayı başkasına devretme seçeneği vardı.

Eğer bir müteahhitseniz ve sözleşmenizde hataların düzeltilmesinden sorumlu olacağını belirtiyorsanız, bu tamamen farklı bir hikaye.

İşverenin çok uzun zaman aldığınızdan şikayet etmesi yanlış mı? Kesinlikle hayır, ama sizi sorumlu tutamaz ve sizi bunun için kovamaz. Size, "Becerilerinizi gerektiren başka bir hatamız yok ve izniniz var" diyebilir, ancak düzeltebileceğiniz yeni bir konunun ortaya çıktığı anda size söylemeliler. Aksi takdirde kıdem tazminatı ile feshetmeleri gerekir. Yapamayacağı şey, size çalışamayacağınız ve başaramayacağınız ve bundan şikayet edebileceğiniz şeydir. Bence bu yasal değil.

Programlamayı ve problem çözmeyi seviyorum ama işimi gerçekten çok zor buluyorum.

Zor bulduğunuz bir işi almakla işvereniniz arasında size vermesi zor olan bir fark var. Size verilen görevlerin sizi şirkette kariyer yapmaktan caydırmak için yapıldığını düşünüyorsanız, bu yasadışı olabilir.

Aslında yaklaşık 10 yıldır programcı oldum. Ama bu benim çok iş parçacıklı ilk gömülü linux işim - 2 senedir buradayım ve hala mücadele ettiğim herkese açık.

Bu yüzden kendini yapıcı bir işten çıkarmanın ortasında bulduğunu düşünüyorum. Seninle mutlu değiller, bu yüzden sen ayrılıncaya kadar seni mahvediyorlar.

Ve sanırım işimin başında sahip olduğum ateşin çoğunu kaybettim, o kadar moralsizleştim ve kendimi çok marjinal hissediyorum.

İşveren, güvenli ve olumlu bir çalışma ortamı sağlamaktan sorumludur. Daha fazla bilgi olmadan (büyük olasılıkla kişisel) yabancıların burada gerçekten neler olduğunu söylemek zor. Bir iş avukatından ücretsiz danışmanlık isteyin. Oynanıp oynanmadığını size söyleyebilecekler.

Referanslar

Ben avukat değilim, ancak Google incelemeye girmeden önce okumaya değer olan Yapıcı işten çıkarma konusunu ele alan bazı belgeler yaptı. Buradaki en önemli nokta, şirkette maaş, aşağılanma ve ani değişikliklerde düşüşe dikkat etmektir.

İlgili gerçeklere dikkat edin:

• Zorlu çalışma koşullarında bir çalışanı doğru şekilde desteklememek
• Bir çalışanın aşırı disipline edilmesi Çalışanın işyerinde kısa sürede değişiklik yapılması
• Maaş veya ücretlerde indirim koyma

Yasal Soru-Cevap: Yapıcı işten çıkarılma

Yapıcı işten çıkarılma talebinde bulunma nedenleri

Vikipedi

Yapıcı işten çıkarma unsurları

Belki de bir projenin orijinal programcılarından biriyle karşılaştırılıyorsunuzdur. Üzerinde çalıştığım projelerden birinin orijinal geliştiricisi olarak, içindeki hataları düzeltirken çok büyük bir avantajım olduğunu biliyorum. Belgelendirme eksikliğinden kaynaklandığını sanmıyorum, sadece potansiyel sorunlara sezgisel olarak sıçrayabildiğim için çünkü beynim tüm kodu biliyor.

Eğer bununla karşılaştırılıyorsanız, sadece ölçüm yapmayacaksınız. Projeye ayak uydurmak her zaman daha fazla zaman alacaktır ve tüm potansiyel etkileşim noktalarının nerede olduğunu bilemeyeceksiniz.

Diğer programcıların sorunları çözmek için kullandıkları araç ve püf noktaları hakkında bilgi edinmeme konusundaki yorumunuzu okudum. Belki bir sonraki hata düzeltmeniz için çift programlamayı denemeniz gerekir. Bu inanılmaz derecede faydalı olabilir. Sırayla klavyeyi sürün. Bir Do çok konuşma.

İşlev yollarını, konuları ve kilitleme ömrünü belirlemek ve çeşitli davranış parçalarını nerede gözlemlediğinizi ve yeni probları nereye yerleştirebileceğinizi işaretlemek için bir dizüstü bilgisayarı veya beyaz tahtayı kullanabilirsiniz.

Bu tür düşük seviyeli diş açma problemlerini çözmek gerçekten zor olabilir ve size çok fazla sempati duyuyorum. İki satırlı bir sorunu tespit etmeden önce birkaç gigabaytlık günlük dosyasını analiz etmek zorunda kaldım. Ve ne biliyor musun? Bir yıl önce stajyer olan genç bir mühendisden yardım istemeden önce günlerce baktım ve yeni bir yaklaşımla ortaya çıktı ve bir saat içinde sorunu tespit etti. Yani, bir hataya biraz zaman ayırdıktan sonra, üzerine yeni gözler getir. Çok yardımcı olabilir!

Bu sektördeki en yaygın yönetim işlev bozukluklarından biri, hata ayıklamanın kendinden zor olduğunu anlamak değildir . Neredeyse 20 yıllık bir deneyime sahibim ve hala düzenli olarak tam bir haftayı, programın ellide bir kez çökmesine neden olan bir satırlık hatayı bulmak için harcamam gerekiyor. Ve sonra, eğer menajerim bu şeyleri anlamıyorsa, bir kod satırını değiştirmek için beni bir haftalığına zorluyor.

Bu konuda ne yapabilirsin?

• Hata ayıklama yaparken not alın. Sadece her zaman bir editör penceresi açın ve bilinç akışınızı yazın. Senden başka kimseye mantıklı gelmek zorunda değil. Bunun daha hızlı hata ayıklamanıza yardımcı olduğunu görebilirsiniz, ancak aynı zamanda tüm hafta boyunca Nethack oynamadığınızı göstermek için somut bir şeyiniz olduğu anlamına da gelir.

• Tüm iş arkadaşlarınızla notları karşılaştırın. Hataların giderilmesi genellikle ne kadar sürer? Böcekleri sabit mi kalıyor? Ne sıklıkta küçük bir şeyi değiştiriyorlar ve kendilerini bir basamaklı sonuç yığını altında gömülü buluyorlar? Bu soruların cevapları size bölümün geri kalanına göre gerçekten mücadele edip etmediğiniz konusunda bir fikir verecektir .

• QA çalışanları ve müşteri destek personeli ile arkadaş olun. Böceklerin ne kadar önemli olduğu konusunda en iyi fikirleri olanlar onlar . Genellikle bunun böceklerin ne kadar zor olduğu ile çok az ilgisi vardır veya hiçbir korelasyonu yoktur , bu nedenle sistemi biraz oynatabilir ve tüm yüksek önemde, düşük zorluk dereceli hatalara atanmaya çalışabilirsiniz. (Bu gerçekten aldatma değildir. İyi organize olmuş bir ekip her zaman bu hataların peşinden gider.)

• Patronunuz size iki yıl boyunca devam eden performansınız hakkında yeterli geri bildirimde bulunmadıysa, bu performans incelemesinde önce ortaya çıkması ve daha sonra da patronunuzun patronu ile birlikte çalışabilmesi için toparlanmaya başlamanız sorun olacaktır. Kibar olun ve özellikle ne kadar sinirlendiğinizi görmelerine izin vermeyin, ancak yazılı olarak belirli eleştiriler alın.

Programlama ve problem çözmeyi sevseniz de, öğrendiklerinizi başka alanlara ne kadar iyi uyguladığınız sorusu olabilir. Bir başkası için yararlı olanı düzeltmenize yardımcı olana benzer bir şekilde düzelttiginiz son düzine ya da öylesine herhangi bir hata var mı? Bu, ne yaptığınıza ve bunu başarmanın ne kadar sürdüğüne bakmanın bir parçası. Dikkate alınması gereken bir fikir.

İkincisi, işinizi nasıl yaptığınıza bakardım. Düzenli olarak kesintiye mi uğruyorsunuz ve böylelikle A hatasını düzeltmeye çalışırken, B ve C hatalarının daha yüksek önceliğe sahip olduğunu mu söylüyorsunuz? İşinizi nasıl yaptığınız konusunda ne tür değişiklikler yapabileceğinizi dikkatlice düşünün, çünkü patronunuzun bilmek isteyeceği şeyin bir parçası.

Bazı iş yerlerinde bana işimin bir kısmını yaptırmanın ne kadar zaman aldığını beğenmediklerini söylediler. Elbette bunlar, bir şeyi yaparsam kucağımda 5 yeni şeyin bırakılacağı ve böylece ezilmesinin kolay olduğu yerlerdi. Artık orada çalışmamaya rağmen, dikkatimi birkaç şeye indirgeme konusunda iyi bir çözüm bulamadım, böylece bir kerede 1000 şeyi ustalıkla yapmaya çalışıyorum gibi hissetmiyorum. Yapılması gereken birkaç önemli şeyi ve işimin nasıl değerlendirileceğini öğrenebilirsem, o zaman bir mil uzunluğundaki bir "yapılacaklar" listeme sahip olmamdan daha iyi biriyim. bunun bir kısmı bitti. Bu nedenle, organizasyonda bunun için kültürel bir bileşen olabilir, ancak burada değişecek şeyleri sormakta dikkatli olacağım.

İşyerinde iki yıl geçtikten sonra, nerede olduğunuza dair herkes (siz, patronunuz, meslektaşlarınız) için açık olmalıdır. Yani, yılda sadece bir kez fakir davrandığınızı asla öğrenmemelisiniz; İdeal bir çalışma ortamı sürekli geri bildirim sağlayacaktır.

Neyse, çok iş parçacıklı kodun nasıl hata ayıklanacağına ilişkin olarak: Bunun sizin kodunuz mu yoksa bir başkasının mı olduğundan bahsetmediniz . Eşzamanlılığı kaldırabilen bazı yeni hata ayıklayıcılar ve statik analizörler var. Fakat gerçekte, kalıpları bilmek en iyi bahis olacaktır, çünkü ne arayacağınızı bileceksiniz.

Kritik bölümlerin ve yarış koşullarının ve kilitlenmenin nasıl çalıştığını anlarsanız, beklenmeyen şeyleri tespit etmek için daha iyi bir konumda olacaksınız. Koşul değişkeni olmayan iki iş parçacığı arasında "iletişim" görürseniz veya belirli bir düzen olmadan kaynakların mutekslenmesi durumunda veya yerel bir değişken staticaçık bir neden olmadan bildirilirse , potansiyel bir hata yaşarsınız ! Böylece, etki alanınızın en iyi uygulamalarını öğrenin; sıra dışı bir şey olduğunda yargılamak için daha iyi bir konumda olacaksınız.

Mecbur kalmadıkça yalnız mücadele etme. İş arkadaşları Böcek avına yardım etmelerini sağla. Onlara düşünce süreçlerini ve araçlarını sorun. Belki de bunu gözden geçirme aşamasında, geliştirme planınızın bir parçası olarak belirtiniz. Etrafınızdaki herkes bu sistemde daha iyisini yapıyorsa , belki belirli bir şey biliyorlardır?

Patronum tarafından Pazartesi günleri olumsuz bir performans incelemesi alacağıma söylenmişti. Neden ben bu kadar yavaş olduğum ve neden hata düzeltme oranımın bu kadar düşük olduğu hakkında konuşmak istiyor.

İşlevsel olmayan herhangi bir şirkette işlerin bu siparişte olmadığına dikkat edin. Patronunuz performansınızla ilgileniyorsa, kısa vadeli hedefler koymalı ve sorunun nerede olduğunu bulmak için sonuçlarınız hakkında konuşmalıdır.

Bunun yerine, size olumsuz bir inceleme yapmaya karar verir, sonra nedenini bulmaya çalışır. Kendisini soruna dahil etmeye istekli değil gibi görünüyor ve sadece tablodaki sonuçları istiyor.

Hataları daha hızlı çözmeyi hedeflemeyin. Kendi yeteneğinizi değerlendirmeyi, meslektaşlarınızın nasıl çalıştığını, ne bildiklerini nasıl bildiklerini kontrol etmeyi ve bunun ideal bir şirket olmadığının farkında olun.

Pratik ipuçlarına gelince, kod snippet'lerini ve not almak için kendi mediawiki'leri kullanıyorum. Her zaman bir sonraki hangi kitapları okuyacağımı ve öğrenmeye devam etmek için hangi yöne gideceğimi aklımda tutar. Öğrenme, daha iyi bir işe ve daha mutlu bir yaşama giden yoldur.

İlk olarak, bir güven artırma:

Neden acı çekiyorsun? Hata düzeltme oranınıza bakılmaksızın Linux'a bir şey ekleyebildiğiniz için kolayca "tanrı" olduğunuzu düşündükleri bir işi kolayca bulabilirsiniz.

Her neyse, böcek avına zaman sınırı koymak imkansız. Böcek avı bir beceridir, şüphesizdir ve buradaki verim çok değerlidir.

Başkalarının bildiği, sizi yavaşlatan temel bir numarayı kaçırıyor olabilirsiniz.

Mesela, sen ve ben bazı Linux ara katman yazılımları üzerinde çalışıyoruz ve ben bellek bozulma problemlerini ve veri yarış koşullarını bulmak için Valgrind kullanıyorum, oysa sadece gdb ve printf'e güveniyor olsanız bile, muhtemelen kıçınızı tekmeleyeceğim sen benden daha zekisin.

Ayrıca, eşzamanlılık anlayışınız nasıl ? On yıldır gelişiyorsanız, ancak bu deneyimlerin çoğu çok iş parçacıklı kodla değildi, bu bir sorun olabilir.

Çok iş parçacıklı çalışmayı ayrıntılı olarak incelemelisiniz: API'lerin nasıl kullanılacağını bilmekten daha fazla, ancak gerçekten derin bir seviyede "alın". Çok iş parçacıklı programlama yapıyorsanız, bir mil öteden bir kod tabanına bakabilen ve yarış koşullarının, çıkmazların, öncelikli inversiyonların, açlığın spot senaryolarına bakabilen geliştirici olmalısınız.

Geçenlerde Legacy Code ile Etkili Çalışma kitabını okudum ve bana herhangi bir kod tabanında bir sorunla uğraşırken önemli bir güven artışı sağladı.

Çalıştığınız kod mükemmel olmayan bir şeyse, bu kitabın yardımcı olacağını düşünüyorum. Bir hatayı düzeltmek için çok fazla zaman buldum, onu anlamak için önce çevreleyen kodu yeniden gözden geçirmem gerekiyor, sonra bir kez kodu anladım ve umarım kodu test edip, izini sürdüm ve Sorunu çözmek bir sıkıntı azdır. (Bazen sadece anlayabilmek için kodu yeniden bile yazdım, ancak daha sonra yeni hataların ortaya çıkma riskini azaltmak için değişikliklerimi geri aldım. Sonra hata düzeltmemi ekliyorum. Bu teknik kitaptan bir numaraya dayanıyor.)

Sanırım önerim yalnızca konunuzun bir kısmını ve biraz dolaylı olarak ele alıyor, ancak eski kodla çalışmak herhangi bir geliştirici için kaçınılmaz olduğu için kitabın ne olduğu önemli değil.

Üstünüze, hataların giderilme hızının ne olduğunu ve ekibin ortalama hataların giderilme hızını sorun. Daha da önemlisi, ona hataların nasıl ölçüleceğini tespit et .

Bu tür bir metrik gerçekten bir metrik değil; eğer öyle olsaydı, LOC'den bile daha güvenilmez olurdu (farklı şeyler ölçmesine rağmen). Ve uygun bir ölçüm olmadan sizi hiçbir şeyle suçlamak için hiçbir sebep yoktur.

Onlar için DEĞİL işveren ve / veya müşteri İLE çalıştığınızı kabul edin. Röportajlarda sadece rekoru baştan itibaren doğrudan belirlemek için tereddüt etmeyin.

Siz küçük işinize yani kendinize çok yatırım yapan bir profesyonelsiniz.

Her gün sizi raftan iten bir Çıkarlar Birliği varken çalışmaya hazırsınız.

Bu itici güç uzun bir süre boyunca orada değilse, devam edin.

Üzerinde çalıştığınız ilgiyi zorlayan ve / veya ilgi çekici ve / veya ilgi alanlarınızı sürekli tutmayan bir serseri işverenine zamanınızı ve enerjinizi boşa harcıyorsunuz. Bu, Yönetim'in işidir. Bunun dışında onlar tepegöz saf .....

Tutkunuzu devam ettirin, anahtar budur.

Benzer durumlarda da bulundum çünkü yardım istemekten korkuyordum. Bu yorumda söylediklerinize bakalım ...

“Ama sinir bozucu olan şey, sadece bir buçuk yıl orada bulunduktan sonra öğrendiğim bazı araçlar / ipuçları / püf noktaları. bu 'gizli' araçlar her zaman çok sık sık. "

... benim de aynı problemi yaşamış olabilirsiniz. Hata ayıklama, her şeyden önce hata ayıklama gerektirmeyen bir kod yazma gibi bir araçtır. Diğer aygıtların hata ayıklama problemi ile çalışmasını izlemek oldukça eğitici olabilir. Bir şeyi çözmede sorun yaşarsanız onlardan yardım isteyin. Özellikle de daha önce sahip olmadığın bir zemini koruyorsan. Panik yapmadan önce bunu ideal olarak yapın çünkü hiçbir şey yapmıyorsunuzdur.

Bu, yönetimin yanlış bir şey yaptığı yorumlarına katılıyorum. Birisi bir şeyle mücadele ediyorsa, olumsuz inceleme eğlencesi başlamadan önce bu konuda yardım almalılar. Cehennem, eğer bir takımdaki herhangi biri mücadele ederse ve asla yardım alamazsa, o takımın her üyesinin yanlış bir şey yaptığını söyleyebilirim (bu, insanların hata düzeltme oranlarını yakından takip etmelerinin doğrudan bir sonucu olabilir).

OP’de eksik olan, hataları çözmek için izlenen herhangi bir tekrarlanabilir işlemden veya yöntemden söz etmektir.

Dolayısıyla, ilk önce izlediğiniz süreci belgeleyin. İşlemdeki her bir adımın neyi başarması gerektiğini belgelendiğinizden emin olun.

İşlemi aşağıdaki gibi görevlere sahip olarak özetleyebilirsiniz:

1. Sorunun tam olarak ne olduğunu bildirdiğinizden emin olun.
2. Sorunu yeniden oluşturmaya çalışın.
3. Sorunu daha küçük parçalara ayırmaya başlayın
4. Sorunun olası nedenlerini düşünün.
5. Bu hipotezleri test edin

Hataların uzun süredir var olup olmadığını veya son değişikliklerle ortaya çıkıp çıkmadığını bilmek faydalı olacaktır. Hataların kod incelemeleri ve / veya sadece insanların oluşturduğu kodu okumak için yapılan son değişikliklerle tanıtılması yardımcı olabilir.

Bence, sorunu açıkça tanımlayabiliyorsanız, örneğin, "Hataları gidermeye çalışırken test etmek için hipotezleri düşünmekte güçlük çekiyorum", o zaman daha odaklanmış tavsiyeler alabilirsiniz.