8+ yıllık deneyim veya yüksek eğitim, kıdemli bir yazılım mühendisinin tanımı değildir ...
Tam metin 2703 Kelimeler, tahmini öğrenme süresi 8 dakika
Kaynak: Pexels
Son yıllarda yazılım sektörü her geçen gün değişiyor ve birçok değişiklikle birlikte.
Bunların arasında benim en sevdiğim değişiklik, şirketlerin artık yazılım geliştiricilerin belirli bir dereceye sahip olmasını, hatta hiç olmamasını beklememesidir.
Bu hem bireyler hem de işletmeler için harika bir haber.
Çünkü bu sektöre girmek için en önemli şey, bu kişinin yapabilecekleri. Başvuru sahibi programlama problemini çözemezse, lisans veya yüksek lisans derecesine sahip olup olmadığı önemli değildir. MVC modelini anlamazlarsa, büyük O sembolünün ne olduğunu açıklayıp açıklayamayacakları önemli değildir.
Kişisel deneyim: Bilgisayar bilimi derecem var Yazılım mühendisiyken, röportajlar dışında hiçbir zaman büyük bir O hesaplamaya ihtiyaç duymadım. Eğer bir web sitesi güvenilirlik mühendisi iseniz ve saniyede binlerce isteği karşılamanız gerekiyorsa, bunu hesaplamanız gerekebilir, ancak sanırım çoğumuz hiçbir zaman büyük bir O ile uğraşmadık.
İnsanların bu sektöre girmeleri ve büyümeleri için ihtiyaç duydukları bilgiler, derece beklentilerinde bir değişikliğe neden olan el yazısı yazılımındaki çevrimiçi kaynaklar ve deneyim aracılığıyla bulunabilir.
Ancak, özellikle kıdemli geliştiriciler ararken beklentilerdeki değişimin burada duramayacağını düşünüyorum. Bir takımda kıdemli bir yazılım mühendisi olmak için pek çok gereksinim vardır, zengin deneyimden çok daha fazlası ... Daha fazla deneyim iyi bir şey olsa da, bir iş tanımında kendi mühendislerini ölçmek için "8 yıldan fazla iş deneyimi" standart olarak kullanılamaz.
9 yıl çalışmış insanlar olacak, ancak beceriler standartlara uygun değil, aynı zamanda sadece 5 yıl çalışmış insanlar olacak, ancak ihtiyaç duyulan tüm yeteneklere hakim olabilirler.
Ekip için daha değerli olan bu sayıdaki zorlu koşulları değiştirmek isteyebilir. Yazılım mühendisi olmanın ön koşullarının yanı sıra, kıdemli mühendislerin sahip olmasını umduğum nitelikler şunlardır:
İyi programlama becerileri
Umarım bu herkesin düşünebileceği bir şeydir ve burada görünmemek daha iyidir, çünkü bu "normal karşılanan" bir gerekliliktir, ancak genellikle iyi bir mühendisi iyi bir mühendisten ayıran temel unsurdur.
Değişkenleri ve yöntemleri adlandırmak gibi basit şeyler verimliliği büyük ölçüde artırabilir. SOLID ilkesini aklınızda bulundurun (Not: S: Tek Sorumluluk İlkesi; O: Geliştirme Kapalı İlkesi; L: Dimit Kuralı / Richteric İkame İlkesi; I: Arayüz Ayrım İlkesi; D: Bağımlılığı Tersine Çevirme İlkesi) ve sürekli olarak aday kodu arayın ve Ölü kod gereklidir. Testin işlevsel kod kadar önemli olduğundan emin olun, bunlar çok değerlidir.
Kıdemli mühendis, takımda, kodun anlaşılırlığı ve etkinliği arasında bir denge bulabilen ve ekibin bu dengeyi koruyabilmesini sağlayan kişidir.
Kaynak: Pexels
Sebat
Bir kişinin başarısının en sık dile getirilen faktörü, sahip olduğu "azim" dir. Aşağıdaki gibi tanımlanır:
"Sebat, ödüllere ve başkalarının takdirine çok fazla dikkat etmemekle birlikte, uzun vadeli başarılar için tutku ve kalıcılıktır."
Bu aynı zamanda bir yazılım mühendisinin en önemli özelliklerinden biridir. Hepimiz bu durumla karşılaştık ... Kodda bir boşluk buldunuz ve çözmek istiyorsunuz. İlk, ikinci ve hatta ellinci girişimleriniz başarısız oldu ... hayal kırıklığı ortadan kalktı ve kendinize bunu ne kadar yapabileceğinizi sormaya başlamanız çok uzun sürmedi.
Belirli bir teknik lider bir keresinde bana ekibin kıdemli üyelerini ekibin "cooli'leri" olarak gördüklerini söylemişti.
Kulağa biraz sefil geliyor, ancak bir adımda 50 başarısız denemeden sonra hala derin nefes alıp biraz çikolata yiyebilir ve sonunda elli birinci denemede başarılı olabilirim Bu, kıdemli bir mühendis olmak için gerekli niteliktir.
Kıdemli mühendisler, ekibe yazılım geliştirmenin iniş ve çıkışlarında liderlik edebilecek kişilerdir.
Kıdemli bir mühendis değilseniz, ancak hedefiniz buysa, buradan başlayabilirsiniz.
Yeni şeyler öğrenmeye açık
Teknoloji endüstrisinin dünyadaki en hızlı yenilik yapan endüstrilerden biri olduğu, hatta en hızlısı olduğu söylenebilir. Her iki yılda bir, yeni sorunlar getirecek ve hatta mevcut sorunları genişletecek yeni teknolojiler, araçlar veya diller ortaya çıkacaktır.
Geliştiriciler olarak, sürekli değişen yazılım mühendisliği endüstrisine ayak uydurmak için her zaman yeni şeyler öğrenmeliyiz.
En iç çeken şey, bir kişinin hareketsiz durması, uzun yıllar aynı yöntemi veya aynı teknolojiyi kullanmakta ısrar etmesi ve yeni bilgiler öğrenmeye veya yeni şeyler denemeye gerek olmadığını hissetmesidir.
Sık sık "A dilini kullanmak istiyorum çünkü bunu B dilinde çok kolay yapamıyorum" diye duyuyorum. Bunu anlayabiliyorum, ama belki de B dili bu sorun için daha uygun bir ifadedir? Ya da diğer takım arkadaşları B dilinde iyidir ve bir dilin gramerinin ve becerilerinin yazılım mühendisliğinde o kadar önemli olmadığını anlayabilirler.Önemli olan, düşünme süreci ve sistemin anlaşılması ve çeşitli bölümlerinin nasıl etkileşim kurduğudur ... StackOverflow'da her zaman sözdizimi veya hileler bulabiliriz.
Bahsetmiyorum bile, yeni şeyler öğrenmek aynı zamanda yeni deneyimler ve yeni düşünme yolları demektir. Yeni perspektifler her zaman memnuniyetle karşılanmalıdır.
Kaynak: Pexels
Küresel bir bakış açısına sahip olun
Bazen bu, bir bireyin şirkette ne kadar süre kalabileceği ile doğrudan ilgilidir.Çalıştığım en iyi kıdemli mühendisler, kafalarında tüm sistemi detaylı bir şekilde anlayabilir. Böylece, bir işlevin uygulanıp uygulanamayacağını ve nasıl uygulanabileceğini hızlı bir şekilde anlayabilir ve hatta bir adım daha ileri giderek hataya neyin neden olduğunu hızlı bir şekilde belirleyebilirler.
Bir zamanlar bir takım arkadaşım vardı.Bir hatayı birlikte ele aldığımızda, koda bakmadan bana doğrudan söyleyebilirdi. 25. satırdaki A dosyası veya 47. satırdaki B dosyasıyla ilgili sorun olabilir. İnanılmaz.
Bu örneğe ulaşmak zor, ancak sistem üzerinde genel bir kontrole sahip olmanın faydaları apaçık ortada.
Bilgiyi paylaş
Her zaman kıdemli mühendislerin en önemli sorumluluklarından birinin ekip üyelerinin kendilerini mümkün olan en kısa sürede geliştirmelerine yardımcı olmak olduğuna inanıyorum.
Bu, aşağıdakileri içerir, ancak bunlarla sınırlı değildir:
· Ekibin sadece yetenek rezervi olmadığından emin olmak için ekipteki diğer geliştiricilerle programlar yazın.
· Karmaşık görevleri yerine getirirken, çözümü ekipteki diğer kişilerle paylaşın Bu süreç ayrı bir toplantıda gerçekleşebilir. (Çoğu ekip, öğrendiklerini veya ekibin bilmesi gerekenleri paylaşmak için konferans görüşmesinin sonunda genellikle bilgilerini paylaşır)
· Takım arkadaşlarının öğrenmesine ve onları mücadelede desteklemesine izin vermek arasındaki farkı bilin ve aynı zamanda tutumlarını dengeleyin, böylece takım arkadaşları kendilerini yetersiz değil de kendinden emin hissederler.
Aslında, kıdemli mühendislerin, genç mühendislerin belirli bir işi bağımsız olarak tamamlamasına izin verdikten sonra, kişisel olmayan kod incelemeleri yoluyla mümkün olduğunca az öğretmeleri gerektiğini düşünüyorum.
Empati
Son nokta ve kişisel olarak en önemli olduğunu düşündüğüm şey, kıdemli bir mühendisin empati kurma yeteneğine sahip olması gerektiğidir.
Takım arkadaşlarının ellerinden gelenin en iyisini yapmaya çalıştığını anlayın. Herkes hala öğreniyor ve kendiniz dahil öğrenmeye devam etmelidir. Duygusuz bir kod eleştirmeni olmayın, ancak takım arkadaşlarınızın fikirlerinin alaka düzeyini ve potansiyelini görün. Bu davranışlar başkaları tarafından öğretilemez, güven dolu bir ekip oluşturmak ve herkesin kendini güvende hissetmesini sağlamak istiyorsanız, daha gidilecek uzun bir yol var.
Birbirine güvenen bir ekip çok şey başarabilir.
Kaynak: Pexels
Umarım "8 yıldan fazla iş tecrübesi kıdemli bir kişiyi kıdemli yapmaz" dediğimde kimse yanlış anlamaz. Deneyimin çok önemli ve değerli olduğuna inanıyorum. Ama aynı zamanda kıdemli bir mühendis pozisyonundan başlayarak, kişisel yumuşak gücün çok önemli hale geldiğine inanıyorum ve bunu makalede iletmek istiyorum. Bu beceriler, endüstrimizdeki herkesin öğrenmek için çok çalıştığı bir şey olmalıdır.Belki bir gün iş tanımı sadece bir beyaz tahta mülakatı ve 8 yıldan fazla deneyim değil, aynı zamanda ekip üzerinde daha büyük bir etkiye sahip olabilecek bir şey olacaktır.
Tabii ki, bu sadece benim kişisel görüşüm.Kendi öneriniz varsa, lütfen bunları yorum alanında paylaşın ~
Yorum Beğen Takip Et
Yapay zeka öğrenme ve geliştirmenin kuru mallarını paylaşalım
Yeniden yazdırıyorsanız, lütfen arka planda bir mesaj bırakın ve yeniden yazdırma şartnamelerine uyun
