Birkaç hafta önce şirketimdeki yönetim bana kalıcı bir çalışan olmam için bir teklif ve zam verene kadar 12 aylık bir sözleşmem vardı (bunun yeni geliştiriciler için olağan olmadığı bir ülkede yaşıyorum). Özgeçmişimi her zaman güncel tutmayı seviyorum (özellikle COVID göz önüne alındığında), bu yüzden özgeçmişimde listeleme konusunda Google'da araştırma yaptım.
Bulduğum tavsiyeler genellikle işe alınmama neden olan başarının ne olduğunu listelemem gerektiği yönündeydi. Yeterince makul.
Sorun şu ki, başarı her zaman sıkı müşteri teslim tarihlerinde teslim ediliyordu ve açıkçası, mühendisliğin hedeflenen durumlarda yıldızdan daha az olabileceğine karar vererek yaptım (yönetim bunu kabul etti).
Ben 6 geliştiriciden oluşan bir ekipte nispeten kıdemsiz bir geliştiriciyim. Bununla birlikte, bir şeyleri teslim edeceğimi söylediğimde teslim etme ve oraya ulaşmadaki göreceli değiş tokuşlar hakkında onları bilgilendirmek konusunda yönetimin en çok güvendiği geliştiricilerden biri haline geldim. Burada geçirdiğim kuşkusuz kısa sürede, bir şeyi teslim edebileceğimi söylediğimde her zaman teslim edebildim.
Bunun gibi birkaç vakam oldu, ancak bu, bana kalıcı iş teklif edilmeden hemen önce yaptığım bir işti. Ürünlerimizden biri, tek bir müşteri tarafından günde bir kez çağrılan bir toplu API. E-posta yoluyla başarısız girişlerin CSV'si dışında bir şey döndürmesi gerekmiyor. Yeni bir özelliğin eklenmesini istiyorlardı ve satış elemanı sözleşmeye göre ay sonuna kadar bu özelliği onlar için hazırlamayı kabul etmişti. Çeşitli nedenlerden dolayı, bu özellik talebi ayın son haftasının Pazartesi gününe kadar bize ulaşmadı.
Kıdemli geliştirici, yöneticiye geliştirmenin düzgün bir şekilde yapılamayacağını ve müşteriye bunun yapılamayacağını söylemesini söyledi. Sprint planlama toplantılarında kıdemli geliştiricilerle ters düşmedim, ancak belki de kıdemli adamla aynı fikirde olmadığım açıktı. Aynı fikirde olmasam da belirli ödünler içeren bir seçenek mevcuttu. Diğer geliştiriciler de oldukça pasifti, bu yüzden başka kimse de onunla çelişmedi. Müşteri, söz verdiğimiz halde teslimatı yapmadığımız için bize zaten kızgın olduğu için yönetici bu durumdan memnun değildi. Müdür toplantıdan sonra beni ofisine çağırdı ve bir alternatif görüp görmediğimi sordu. Ona işe yarayacak bir şeyler bulabileceğimi söyledim, ancak özel SQL becerilerim olmadığı için muhtemelen API'nin işlem süresini iki katına çıkaracaktı (bu da 4 dakika ekleyecekti). Müdür kabul etti ve görünüşe göre müşteri fark etmedi bile.
Son teslim tarihini kaçırmanın sonuçlarının ne olacağından emin değilim, ancak 1000 kişilik şirketimizin CEO'sunun bunu teslim ettiğim için bana bir teşekkür e-postası göndermesine neden olacak kadar ağırdı.
Başka bir vaka o kadar dikkat çekmedi, ancak bir veritabanı üzerinde çalıştırmamız gereken bir süreç vardı. Bunu yapmanın doğru yolu, kullandığımız mega Java sisteminde uygun bir toplu işlem yazmak, tüm normal QA süreçlerinden geçirmek ve iki hafta sonra çıkmasına izin vermek olurdu. Yöneticiye manuel olarak çalıştırılması gereken ve korkunç derecede verimsiz olacak (gece boyunca çalıştırmak zorunda kalacak), ancak ayda bir tetiklenirse kalıcı bir düzeltme gelene kadar sorunu uzak tutacak bir Python betiği önerdim. Bu bir üretim sorunuydu, bu yüzden geçici bir önlem olarak bunu kabul etti. Bu temelde, belirli bir hatalı veri türü için satırları kontrol eden ve yeniden biçimlendiren ucuz bir for döngüsünden ibaretti.
Bu tür şeyleri özgeçmişimde listelemenin, beni kıdemli geliştiricileri baltalayan bir programcı gibi göstermeyecek bir yolu var mı? Çözümlerimin teknik olarak sağlam olmadığını kabul ediyorum, ancak o zamanki iş ihtiyaçları için sağlamdılar ve verimsizlik değiş tokuşu çoğu durumda büyük ölçüde önemsizdi.
Sorunları aşırı mühendislik yapmadan çözmenin birkaç etkili (verimli değil) yolunu buldunuz ve "Yapılan mükemmelden daha iyidir"
Yeterince iyi bir çözüm bulmak bir mühendis için önemli bir yetenektir, aksi takdirde optimize etmeye değmeyecek bir şeyi optimize etmek için çok zaman harcarsınız. Bir şey sık kullanılmıyorsa, onu optimize etmeye genellikle değmez. Bir şeye ne kadar zaman ayırmanız gerektiğini gösteren bir tablo içeren güzel bir XKCD-Comic vardır.
Bir çözüm ancak kullanıldığında (veya kullanılabildiğinde) bir değer taşır, bu nedenle bir hack ile müşterinin bir çözüm elde edene kadar çalışmaya devam etmesini sağladınız.
Amirinizle aynı fikirde olmadığınızı kimseye söylemenize gerek yok. Sadece "Zaman baskısı altında etkili çözümler üretebilme" gibi bir şey seçin.
Çözümlerimin teknik olarak sağlam olmadığını kabul ediyorum, ancak o zamanki iş ihtiyaçları ve verimsiz ticaret için sağlam kapalı çoğu durumda büyük ölçüde alakasızdı.
Tek bir işiniz vardı: "zaman sınırları içinde çalışan ve işi çözen bir çözüm bulmak". Ve yaptığınız da tam olarak buydu.
Ne demişler "Mükemmel iyinin düşmanıdır" - iş ihtiyaçlarını karşılamak için teknik ödünler vermek hemen hemen bir zorunluluktur. İyi geliştiriciler/programcılar/mühendisler, yapılabilecek kabul edilebilir ödünleri belirleyebilenlerdir.
API örneğinizde müşteri, çalışan ve zamanında teslim edilen bir şey için işlemde 4 dakikalık bir gecikmeyi kabul etmeye açıkça daha istekliydi.
İdeal olarak bu ödünleri verirken teknik borcu en aza indirmeye çalışmalısınız - ancak bu tamamen deneyimin bir parçasıdır ve nerede zaman kazanabileceğinizi ve uzun vadede daha fazla zaman kazanmak için bir şeyin "doğru" yapıldığından emin olmanız gerektiğini bilmeniz gerekir.
Benim temel sorum, özgeçmişimde bu tür şeyleri listelemenin bir yolu var mı, bu beni kıdemli geliştiricileri baltalayan bir hack programcısı gibi göstermiyor mu?
CV'niz söz konusu olduğunda, çözümünüzün ayrıntılarına girmenize gerek yoktur - sadece zamana duyarlı projelerde son teslim tarihlerine uyma konusunda iyi bir geçmişe sahip olduğunuzu söyleyebilir ve gerçek uygulamanın ayrıntıları olmadan örneklerden bahsedebilirsiniz.
Yaptığınız şey "hacklemek" DEĞİL, "çözüm bulmak".
Ben 20 yıldır geliştirici ve danışman olarak çalışıyorum ve işverenlerin aradığı şey bu beceridir: Bunu özgeçmişinizden çıkarmayın ama tam olarak bunu vurgulayın: Alışılmadık yollardan gitmek anlamına gelse bile çözüm bulmaya çalışıyorsunuz.
Bunu kıdemli geliştiricilerin arkasından yaptığınızı yazmayın, ancak daha deneyimli kişiler aynı fikirde olmasa / mümkün olmadığını söylese bile çözüm için sorulduğunda bunu yaptığınızı yazın.
Albert Einstein'dan geldiği söylenen ve tam da sizin durumunuzu anlatan harika bir söz var:
Herkes bunun imkansız olduğunu biliyordu, ta ki bilmeyen bir aptal gelip bunu yapana kadar.
Çok sayıda geliştiriciyle birlikte çalıştım ve bu işin her yönünü biliyorum:
Stackoverflow'da JavaScript uzmanlarının ilk %1'i arasında yer alan bir geliştirici ile çalıştım. O bir dahi ve yazdığı her kod satırına gerçekten hayranım. Ancak çoğu zaman projelerini bitirmezdi: Kodun güzelliğinden memnun olmadığında bir şeyi bitirmektense bitirmemeyi tercih ederdi.
Ve son derece verimli olan, ancak bu nedenle çözümleri neredeyse sürdürülemez hale getiren (sabit kodlanmış yollar, sihirli sayılar vb.) birçok kısayol kullanan geliştiricilerle çalıştım.
Ve ben her zaman "bitmiş" olanı "güzel" olana tercih ettim ve sonuçta müşterilerim de öyle yaptı: Son teslim tarihi geldiğinde "bir şey" olmasını "hiçbir şey ama biraz daha zaman içinde güzel olacak X" olmasına tercih ederler;
Sadece bir şey: Geçici çözümler / kısayollar / "hack" anlaşılabilir, belgelenebilir ve sürdürülebilir olmalıdır, o zaman sizin gibi çözümlere karşı hiçbir şey yoktur