g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Yazılım mühendisliği sektörüne ilk girdiğinizde kolayca yapabileceğiniz en büyük hataya düştünüz mü?

Tam metin 2526 Kelimeler, tahmini öğrenme süresi 8 dakika

Kaynak: Pexels

Üniversiteden mezun olduğumda, hedeflerim yoktu ve borçluydum, ancak kayıtsızdım ve "profesyonel" yazılım mühendisliği endüstrisinde çok çalışmak istiyordum.

Agile'ı daha önce tanıdım ve stajım sırasında az çok kullandım. Sınıflarda, kişisel projelerde ve farklı işlerde birçok kod yazdım. Ayrıca becerilerini bazı tasarım şemalarında ve genel düşüncede denedi.

O zamanlar, çoğu acemi mühendis ile aynıydı: en iyi mühendis olmak için en büyük potansiyellerini öğrenmek, geliştirmek ve oynamak için istekli.

Bundan dolayı birçok hata yapıldı. Çalışmanın ilk iki haftasında yanlış kod yazdım ve bir meslektaşımın fazla mesai yapıp raporu zamanında göndermesine neden oldum.

Ancak yazarın yaptığı hataların çoğu yanlış koddan veya projenin zamanında tamamlanamamasından kaynaklanmamaktadır (bu iki durum da zaman zaman ortaya çıksa da). Hatanın nedeni yazarın cahil görünmek istememesidir. Çoğu insan bu duruma sahtekâr sendromu adını verir. Bir fikri, kavramı ya da ağacı nasıl geçeceğimi anlamadığımı itiraf etmekten korkuyorum.

Bu korku, yazarın kariyerinin başında bazı hatalar yapmasına neden oldu. Umarım bu hataları paylaşarak aynı hataları yapmaktan kurtulabilirsiniz.

Çok az sordum

Kaynak: Pexels

Bunu çok iyi biliyorum, ancak kendimi bilgisiz bulduğumda, yine de başkalarından tavsiye istemedim, bunun yerine, kendimi yersiz hissettim ve Google ve Stackoverflow aracılığıyla duyduğum fikirleri aramaya çalıştım. (İyi geliştiriciler bunu yapar, değil mi?)

Toplantı sırasında, grubun diğer üyelerinin düşüncelerini sadece sessizce dinledim ve düşüncelerim hakkında konuşmamı istemeyeceklerini umarak sessizce başımı salladım.

Kodu yazarken, gördüğüm kötü kod içinde sıkışıp kaldım (yazarın ilk işi çok anlaşılmaz bir faturalandırma sistemi başlatmaktı) ve daha fazlasını okuduğum sürece er ya da geç anlamayı bekliyordum. Yazar hiç anlamadığım kodlara çok zaman harcıyor, çünkü başkalarından anlamadığım kısaltmalar ve terimler sormaya cesaret edemediğim için.

Soru sormak için cesur olun! Bir soruyu ilk kez anlamazsanız, yeteneğinizin onu anlamak için yeterli olmadığı anlamına geldiğini düşünmeyin. Tüm meslektaşlarınız buraya geldi ve kampüsten ilk ayrıldıklarında onlar da eksikti. Ayrıca öğrenme sürecinde yardıma ihtiyaçları var, bu yüzden cesaretinizi kırmayın.

Hatta bazıları senin gibi herkesle tutarlı olmaya çalışıyor olabilir. Sayısız mühendis toplantıda anlaşmak için sessizce başını salladı, ama aslında toplantıda ortaya konan fikirlerin ne anlama geldiği hakkında hiçbir fikirleri yoktu.

Sesini yükseltmekten utanmak yerine, takıma yardımcı olacak sorular sormak daha iyidir, örneğin:

· "Tablo bölümleme hakkında az önce bahsettiğiniz şeyi tam olarak anlamadım. Tekrar açıklayabilir misiniz?"

· "Bu projenin nasıl yapılandırıldığını tam olarak anlamıyorum. Daha fazlasını öğrenmem için bana bazı belgeler verebilir misiniz?"

· "Son zamanlarda Ansible'ı kullanmayı öğreniyorum, ancak bazı darboğazlarla karşılaştım. Birkaç soruma cevap verebilir misiniz?"

Çok fazla konuşmak

Kaynak: Pexels

Yazar çok az soru sordu ama çok fazla şey söyledi. Dahası, konuşulan kelimeler çoğu zaman gerçek bilgi rezervleriyle orantılı değildir.

Yazar, bir yıl çalıştıktan hemen sonra bu sorunu keşfetti. O zamanlar, zaten çok fazla bilgi öğrenmiştim, artık işyerine yeni gelmediğimi hissettim ve çalışırken öğrendiklerimi göstermek istedim. Yazar, farklı çalışma yılları için yapılabilecek hata türlerinin farklı olduğuna inanıyor, bunu hatırlamak çok önemli.

Yazar düşüncelerini ifade etme konusunda endişeliydi ve kendisiyle çok gurur duyuyordu ve başkalarının fikirlerini dinlemek istemiyordu.

Yapmakta olduğum bir proje parçalanana kadar davranışımı fark etmemiştim. Yazarın ekibine birkaç kıdemli mühendis atandı ve sonuçlarımızın kısa bir incelemesinden sonra, yaptıkları hataları belirtmeye başladılar. Projenin başlangıcından itibaren, ekibin projenin kalitesini ve miktarını sağlamak için birkaç deneyimli mühendise sahip olması gerektiği doğrudur, ancak bu kontrol edilebilecek bir şey değildir.

Bu süreçte ne yaptığımı hala bilmediğimi fark ettim. Yazar, öğrenecek çok şey olduğunun farkındadır. Dinlemeyi öğrendim, kendi sorularımı tekrar sormaya başladım ve her şeyi bilen ve her şeye kadir olmadığımı kabul ettim.

İş yerinde de benzer durumlarla karşılaşabilirsiniz. Örneğin, Zengin Beş Araba öğrendiğinizi hissettiğinizde, birdenbire öğrenecek çok şeyinizin olduğunu fark edersiniz. Bu, işyerinde mümkün olan en erken zamanda gerçekleştirilmelidir. Her şeyi bilen olmadığınızı ne kadar erken anlarsanız, o kadar çabuk öğrenmeye ve ilerlemeye başlayabilirsiniz.

Yalnızca işle ilgili kodu yazın

Kaynak: Pexels

Yazar bu noktada çok acı çekti. Artık kendi kodlama becerilerimi geliştirmiyorum, sadece elimdeki göreve odaklanıyorum.

Başarılı bir mühendis olmak için atanan koda ve projeye odaklanmanın kaçınılmaz olduğu açıklığa kavuşturulmalıdır. Bununla birlikte, umarım haftada iki saatimi açık kaynak geliştirmeye veya LeetCode veya TopCoder'de bazı zorlu kodlar yazmaya ayırabilirim.

Bunu söylüyorum çünkü bir süre çalıştıktan sonra, proje kodunun temel içeriğinin çoğu sadece kod konseptinin bir kısmı ile ilgilidir. Yazarın mevcut çalışma içeriği, RESTful API'ler aracılığıyla yüksek verimli, düşük gecikmeli dağıtılmış hizmetler oluşturmaktır. Bu çalışma gerçekten zor olsa da, işin içeriğini bildikten sonra iş içeriğinin çoğu oldukça benzer. Bu nedenle, sorunu çözme yöntemimin neredeyse aynı olduğunu buldum.

Ancak yazar, uzun süredir bir görüntü motoru veya basit bir metin editörü (ve diğer araçlar) gerektiren işler yapmadı. Bu araçlarla çalışmanın eşit derecede zor olup olmadığından bile emin değilim, ama eminim öyledir.

Çalışma projesi dışında kodun içine girmek, kod yazma düzeyini korumanın mükemmel bir yoludur ve aynı zamanda, bazı açık kaynak katkıları yaparak özgeçmişinize parlaklık katabilirsiniz. Haftada sadece birkaç saat ile, kodlama becerileri büyük bir hızla ilerleyecektir. Bunu işte yapacak vaktiniz olmadığını düşünüyorsanız, ofis saatleri içinde yapıp yapamayacağınızı öğrenmek için bir yönetici ile görüşün. Sonuçta, kodlama becerileriniz gelişti, bu hem kendiniz hem de şirketiniz için iyi bir şey.

Yazar birçok hata yaptı, ancak yazar yukarıdaki noktaların en etkili olduğuna inanıyor.

İlk iki hata, nihayetinde cahil olmak istememekten veya diğerlerinden daha iyi olmayı istemekten kaynaklanmaktadır. Böyle bir kısır döngüye girmeyin. Başkalarının sizin hakkınızda ne düşündüğünü çok önemsediğinizde, başkalarının sizi hiç umursamayabileceğini unutmayın.

Üçüncü hata türünün klişe olduğu söylenebilir. İşyerine girdikten sonra, yazar beni yazılım mühendisliği endüstrisine götüren becerileri, yani kod oyma konusundaki ısrarı görmezden geldi. Kıdemli mühendisliğe terfi ettiğimden beri, yazar, çalışma projesiyle hiçbir ilgisi olmayan daha fazla kod yazdı. Bunu yapmak, yazara çalışmada pek çok fayda sağlar (kod yazma hızı da büyük ölçüde artar!).