Bir “Teorisyen” programcısına başvurmaktan kaçının

Bu yazıyı SO ile ilgili birkaç mesajda buldum . Kendimi 6. arketip içine düşerken buluyorum; "Teorisyen".

"Teorisyen" i şöyle tanımlar:

Teorisyen programlama hakkında bilmeniz gereken her şeyi bilir. Belirsiz bir programlama dilinin tarihi hakkında ders vermek veya yazdığınız kodun tamamen optimalden daha az olduğuna ve çalıştırılması için fazladan üç nanosaniye alabilir olduğuna dair bir kanıt sunarak dört saatini harcayabilir. Sorun şu ki, Teorisyen yazılım geliştirme hakkında hiçbir şey bilmiyor. Teorisyen kod yazdığında, sadece ölümlülerin anlayamayacağı kadar “zarif” olur. En sevdiği teknik özyinelemelidir ve her kod bloğu, zamanında ve okunabilirlik pahasına, maksimuma ayarlanmıştır.

Teorisyen de kolayca dikkatini dağıtıyor. Bir saat sürmesi gereken basit bir görev Teorisyenleri üç ay sürüyor çünkü mevcut araçların yeterli olmadığına karar veriyorlar ve yüksek standartlarını karşılayan yepyeni bir sistem inşa etmek için yeni kütüphaneler inşa etmek için yeni araçlar inşa etmek zorundalar. Teorisyen, projenin sınırları dahilinde oynamasını ve The Ultimate Sorting Algorithm'de çalışarak vakit geçirmeyi bırakmasını sağlayabilirseniz, en iyi oyuncularınızdan birine dönüştürülebilir.

Neyin basit bir proje olması gerektiği üzerinde çalışırken bile, her şeyi sıfırdan baştan yürütmeye çalışırken donma eğilimindeyim (Bu muhtemelen neden 2 yılını sıfırdan bir işletim sistemi yapmaya çalışırken boşa harcadığımı açıklıyor. sonunda anlamsızdı).

Bunu yapmaktan kaçınmama ne yardımcı olabilir? Ve KISS ilkelerine bağlı kalmak?

Teşekkürler

Doğanın bir Teorisyeni olarak kendim, size çevik bir mağazada çalışmanın bu tür eğilimleri hızla ve kararlı bir şekilde iyileştireceğini söyleyebilirim. Özellikle, çift programlı (sık sık dönen), test odaklı geliştirme, zaman boks ve sınırlı sprintleri olan bir eXtreme Programlama işlemi, tüm çalışma arkadaşlarınızın görmesi için hemen çalışmanızı sağlar ve açıp birlikte çalışmanızı gerektirir. bir dakika-dakika esasına göre. Bu, Teorisyen tarzı çalışmanın geliştiği yalıtılmış ofis ortamındaki ayrı görevlerden çok büyük bir kaymadır. Herkes sürekli olarak herkese aktif olarak bağlı olduğundan, tam bir dürüstlük ve toplam bütünlük gerektirir.

Göbek bakıcılığımı hala değerlendiriyorum, ancak bunu evde ya da ana gelişimin bir parçası olmayan bir proje üzerinde çalışabileceğim ender durumlarda şımartmak zorundayım.

1. Geliştirmeniz gerekenler için hedefleriniz var.

2. Bu hedefleri yakın gelecekte verilebilecek bir şeye daraltın.

3. Sonra diğer tüm düşünceleri ortadan kaldırarak bu hedeflere odaklanın. Arkaplan yok. Tarih yok. Uzantı yok. Genel veya soyut bir şey yok.

4. O zaman onları daha da daraltın, en azından bunu yapabileceğiniz bir şey olabilir. İyi değil. Esnek değil Bakımı mümkün değil. Sadece Kabul Edilebilir.

5. O zaman yapabileceğiniz en az başarıya ulaşmak için gereken mutlak asgari seviyeye öncelik verin. Önemli olan, yaklaşık bir hafta içinde bir tarih seçmek ve o tarihe doğru ilerlemektir. Bir haftada bir şey teslim edemezsen. Dar. Odak. Trim. Azaltın.

6. Sonra kabartmayı giderin. Sadece bir haftan var. Kesmeye devam et.

7. O zaman mümkün olduğunca erken yapılacak azaltılmış bir uygulamaya odaklanın. İdeal olarak, bir haftadan az, bu yüzden dokümantasyon yazmak için zamanınız var.

Teorisyenlerle çalıştım. Başarısız olarak nitelendirilebilecek bir şeyi yapmaktan kaçınmak için "ekstralar" bahane buluyorum.

Yapmak - ve başarısız olmak - zordur. Bir şey yapmak hakkında konuşmak, bir şey yapmaktan daha kolaydır. Bir çok araştırma ve düşünme, yanlış olanı yapmaktan kaçınmanın ve ardından kullanıcıların yalan söylediklerini öğrendikten sonra tekrar çalışmanın bir yoludur.

Sadece önlerine kod koy. Kodu bir hata olarak adlandırırlar. Olur. Ancak başarısızlık sürecinde gerçek gereksinimlerin ne olduğunu öğreneceksiniz. Ve yalan söylediklerini öğreneceksin.

Bunun böyle kötü bir şey olduğundan emin değilim. Açıkçası, üretken olmanız gerekiyor ya da işinizi yapmayacaksınız, ancak alana ilgi duymak, sanat öğrencisi olmak, yani konuşmak kötü bir şey değil.

Güçlü yönlerinizle oynar, stilinizin ve tercihinizin bir avantaj olduğu fırsatları araştırırdım.

Erlang'da bir MVC çerçevesi yazarken (veya ilginç bulduğunuz her ne ise) üretken kalmanızı sağlamak için, belki de daha ezoterik çalışmalarınızı günde bir saat yapmak için zaman kutucuğuna eklemelisiniz. Günün geri kalanı için sadece homurdanmaya odaklanın ve işi halledin. Dikkatinizi dağıtacak ilginç bir şey gördüğünüzde yer imi veya not alın ancak devam edin, sonra ayrılan zaman diliminize geri dönün.

Şahsen ben ilginç göründüğü URL'ler ve bir yığın kütüphane kitabım var. Belki de sonunda bu URL’lerin% 10’una yaklaşıyorum ve sonunda kitapların% 50’sini okudum, ama yine de günlük işlerimi yapıyorum.

Bu sorunu kendim de yaşadım. İki teknik yardımcı oldu:

1. Pomodoro tekniğini veya çok kısa vadeli hedefler dizisi koyduğunuz başka bir zaman yönetimi tekniğini kullanın. Önümüzdeki 25 dakika içinde neler başarabileceğinizi anlamak zorunda kaldığınızda, işe yarar bir işe odaklanmanızı sağlıyor.
2. Test odaklı geliştirme. Herhangi bir kod yazmadan önce somut bir test yazmanız gerekirse, hayal kurmayı en aza indirir. ("Zarif" için bir test yazmanın bir yolu yoktur.) Bir şeyi yaptıktan sonra, yeniden düzenlemekten daha fazla zaman harcayabilirsiniz, ancak en azından hayali bir idealden ziyade gerçek kod üzerinde çalışacaksınız.

Kendini çok fazla dövme. Bir Teorisyen'e odaklanmak ve faydalı işler yapmak, umursayan olmayan insanlara ufkunu genişletmelerini sağlamaktan daha kolaydır.

Stackoverflow.com adresinden kaçının . Beni yanlış anlamayın - Ben büyük bir hayranıyım - ama SO ve diğer programlama odaklı forumlar yapmak mükemmel düşmanı iyi . Bir süre sonra, binlerce akıllı insanın omzunuzun üzerinden baktığını ve yazdığınız hiçbir şeyin yeterince iyi olmadığını hissetmeye başlayabilirsiniz. Sadece birşeyin çalışmasını sağlayın ve anlaşılır hale getirmeye çalışın. İyileştirilmesi gerekiyorsa her zaman tekrar ziyaret edebilirsiniz.

Ayrıca, bağladığınız gibi makalelerden de kaçının. On çeşit programcının olduğuna gerçekten inanıyor musunuz? Ya da tanıdığın herkes, tam olarak tanımlanmış kategorilerden birine tam olarak uyuyor mu? Bunun gibi yazıların belli bir çekiciliği var çünkü biraz doğruluk içeriyorlar - kendinizi ve / veya iş arkadaşlarınızdan bazılarını basmakalıp kalıplarda görebilirsiniz. Ancak kategoriler astrolojik işaretler kadar su tutuyor. Bir dahaki sefere konferans sonrası miksere girerken bunu deneyin: "Merhaba, Ben bir Kod Kovboy'um! Türünüz nedir?"

Bu, sorunuzun geçerli olmadığını söylemek değildir - eğer bir şeyi fazla düşünüyorsanız, bu eğilimden nasıl kaçınacağınızı öğrenmek iyidir. Ama bu cezaların seni güvercinle konuşmasına izin verme.

Tamamen açıldığında, bu senaryodan nasıl kaçınılacağını açıklayan basit bir kılavuz var.

İşe yarayabilecek en basit şeyi yap.

- Kent Beck

Sanırım başınızı bulutlardan uzak tutmanın bir yolu, kendinizi teorik API'lerinizi veya çerçevelerinizi yazmanın yanı sıra baştan sona gerçek uygulamalar yazmaya zorlamaktır. Bir şeyin etrafına bir zaman kutusu koymaya çalışın ve bu süre içinde "bitirmeye" çalışın. Çerçeve yazmak, tasarım desenleri ve mimarinin iyi bir şekilde anlaşılmasını gerektirir, ancak sabit bir zaman dilimi içerisinde eksiksiz bir uygulama yazmanın çok iyi tasarlanmış bir çerçeve yazmaktan farklı beceriler gerektirdiğini gördüm.

Eğer bir başvuruyu tamamlamak istiyorsanız, bir noktada kendinizi dünyaya indirmeniz ve yapmanız yeterlidir. Bu, bazı kısıtlamalar nedeniyle, tasarımlardan fedakarlık yapılmasını veya bir özelliği memnun olmadığınız şekilde uygulamanız gerekebilir. Ben senin gibiyim - şeyleri milyonlarca kez yazmaya ve yeniden yazmaya meyilliyim, ancak belli bir süre içinde yapılması gereken görevlerle karşılaşırsam, savaşlarımı seçtiğimi ve yalnızca en önemli şeyler.

Basit:

1. Pragmatik olun .

Teorisyen'in karşı tarafı (programlama alanının bilgi / bilgi tarafında avantajları vardır) Pragmatik'tir.

KISS, DRY, SOC ve diğer düşünce tarzlarını uygulamak, bu cevapta tarif edildiği gibi , arı yetiştiriciliği pragmatik demektir.

Ayrıca bu kitabı okuyarak pragmatik olmayı da öğrenebilirsiniz:

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

Unutma, teori ve pratik birlikte değil, birlikte çalışır. Çok fazla pratik yapmadan, bilginin hiçbir şey olmadığını. Çok fazla bilgi olmadan pratiklerinizi hızlı bir şekilde geliştiremezsiniz.

Yani, çok çalışın. Ve çok şey öğren. Ama birinin diğerini geçmesine izin verme.

Projelerinizde bir son tarih belirleyin. Bağlı kal. Ardından, projenizi son teslim tarihinden önce bitirmenin yolu hakkında pratik düşünün. (kitabı oku, gerçekten) Sonra kodlamaya başla, bilmen gerekenleri okumaya başla, okumadan kodlamaya ve sınırlamaya ya da okuma zamanını değiştir.

Hrm ... Belki de bir zaman çizelgesi altında başvuru yazmanızı gerektiren bir işletmede iş bulmayı deneyin. Kendim için söyleyebilirim ki, muhtemelen en azından işte olabildiğince bir teorisyen olmaktan çok uzaktayım. Bu tür bir iş yapmanın yeri ve zamanı vardır ve kendinizi geliştirmek için önemlidir. Ancak, bu tür bir kabiliyeti takdir ederken iş dünyasında, özellikle çalıştığım yerde hiçbir yeri yoktur. Bazen haftalar içinde uygulama yazdığınız ve müşteriniz dün bunları istediği hızlı tempolu bir geliştirme ortamı! Müthiş geliştiriciler ile kutsandım ve herkesi takım olarak çalıştırmak için zaman harcadım.

Olabildiğince zeki olan bir adamım vardı, ama senin gibi, iyi çalıştığında bile kodunun son küçük kısmını sıkmak zorunda kalıyordu, hatta aslında özel kontroller yazmaya başladığı noktaya kadar. çevre tarafından sağlananlarla aynı. Her şey çok güzeldi ama zamanımızı halletmemiz gereken zaman kaybı. Çoğu zaman bu yan projeler ekibi destekledi ve nihayetinde diğerlerinden gelen baskıyı hissetmeye başladı ve şekillendi. Ürünleri dışarı itmek zorunda olan diğer iyi geliştiricilerle birlikte ekip ortamında çalışmaya başlamanızı tavsiye ederim. Her şeyi yeniden yapmak ve yeniden yapmak ya da şimdiye kadarki en iyi kıçlı MergeSort'u yazmak için zaman vardır; ama bazen ürünü çalıştığı bir noktaya ve müşteriye götürmek zorundasınız.

Kelimenin her zamanki anlamında bir “teorisyen” olmanın yanlış bir tarafı yoktur. Temel bilgiye sahip olmak ve en son CS araştırmalarını anlayabilmek, iyi ve orijinal fikirlerin altın madeni olduğu için sahip olmak için mükemmel bir yetenek.

Buradaki 'gerçek soru' yazının sonraki yarısında daha belirgindir. Belirli bir proje hedefini bilin ve başka bir amaç için değil, bu amaç için çalışın. Bu gerçekten sadece bu durumda öz disiplin meselesi. Bu konuda daha fazla bilgi için S. Lott'un cevabına bakınız :).

Aklınızı programlamadan ve hatta bir şeyler yürütmek için çalışan yazılımı sunmaya odaklayın Önceliklerini belirliyor.

Bunun nasıl başarılacağı başka bir hikaye. En iyi yol, bir projeyi ortaya çıkarmak ve üretime geçirmek için tüm adımları atmaktır. Ondan sonra öncekinden farklı bir zihniyetin olacak.

Bu yazı için teşekkürler. İşimi daha da değerli kılıyor. Bilgi Teknolojileri alanında Yazılım Geliştirici olarak çalışan bir eğitimim olduğunu da hissediyorum. Sık sık kendimi "neyin değişeceği" yerine "şeylerin nerede değiştirileceği" ile mücadele ederken buluyorum. Çok fazla ilişki var, etrafta işlerin nasıl yürüdüğünü bulmak çok uzun süren akıllı ve genel şeyler.

Bu yüzden bu gerçekten inşa edildiğini NASIL ve NEREDEYEN tanıyana kadar sorular sormaya ve daha da fazla soru sormaya başladım. Ve size söyleyeyim - işe yarıyor. Bir yangın ne kadar fazla soru sorsa, orijinal mimariyi devam ettirmek o kadar az önemlidir ve nihayet temel noktalara geri döner

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}

Patronunuzdan bir mentor edinmesini isteyin ve ardından mentorun dediği gibi yapın.

Zor kısım odağı korumaktır ve “hey, işletim sistemini yeniden yazalım” diyerek verilen görevi bitirmek için önemli bir fayda sağlamayacağını (bu nedenle bir proje yöneticisinin yapamayacağının nedeni) kabul etmektir.

Ayrıca, mentöre kodlamadan önce TÜM tasarımlarınızı ve kodlama sonrası gerçek kodu incelemesini sağlayın . Bu, yapılması gerekenlere odaklanmanıza yardımcı olacaktır.

Bazı şeyleri aşırı mühendislik yapmak için aynı cazibeye sahibim ve onu geçmek için öz disiplin ve organizasyon gerekiyor. Başkasını kodlarken, işte nasıl yaparım:

1. Ayrık bir göreve başlarken, işlevsellik, kalite, teslim tarihi, vb. Kadar gerçekte neyin gerekli olduğunu düşünerek birkaç dakikanızı ayırın .
2. Kodun müşterisinin hedeflerini göz önünde bulundurarak, bunun nasıl yapılacağını planlamak , alt görevlere, alt alt görevlere vb. Ayırmak için biraz daha zaman ayırın .
3. Bilinmeyenler için% 50'ye kadar ekleyerek her bir öğe için zamanı tahmin edin . Bir öğenin dört saatten fazla sürmesi durumunda, biraz daha parçalara ayırın. (Üniversite projeleri yapıyor olsaydım, bir elektronik tablo kullanırdım, ancak birden fazla müşterinin danışmanı olarak, Redmine adlı bir sorun takip sistemi kullandım.)
4. En önemlisi: sadece bulduğum eşyaları yap .

Tabii ki, şeyler olur. Bazen daha fazla şey yapmam gerektiğini düşünüyorum - bu yüzden # 1 ile başlıyorum. Bazen bir görevin düşündüğümden daha uzun süreceğini tespit ediyorum - # 1 ile başlayalım. Bazen, tasarımımın daha sonra daha fazla ayrıntıya ihtiyaç duyacağını önceden biliyorum - bu yüzden # 1 ile başlayacağım bir yeniden tahmin alt görevi planlarım.

Bunu ne kadar çok yaparsam, o kadar iyi olurum. Öz disiplin, egzersizle güçlenen zihinsel bir kastır ve ayrıca, ne kadar zaman alacağını tahmin etmeyi ve teknik değiş tokuş yapmayı geliştiririm. Ve General Patton'dan bir alıntıyı hatırlamakta fayda var: “Şiddetle uygulanmış iyi bir plan, gelecek hafta yürütülen mükemmel bir plandan daha iyi.”

Yalnız bir geliştirici olarak, iş akışım bunu Kanban panosu da dahil olmak üzere Çevik özelliklerle birleştiriyor. Bazen teğetlere biniyorum, ancak sapmaları haftada birkaç saatle sınırlandırmaya çalışıyorum ve oldukça iyi çalışıyor.

Özel sektörde çalışmayı planlıyorsanız, "teorisyen" dürtüsünü kontrol etmek gerçekten önemlidir. Bildiğim en mükemmel programcı Silikon Vadisi'nde yaşıyor, ancak çok geç kalmış mükemmel bir kod sağlama konusunda ün yapmış olduğu için yıllarca bir işi yoktu.