Bir programcı hangi şapkayı takmamalıdır? [kapalı]

Tecrübelerime göre, yazılım geliştiriciler birden fazla şapka giyme ve farklı sorumluluklarla birden fazla rol doldurma eğilimindedir. Sadece kodlamadan değil, bazen de SQL yazmaktan, kullanıcı arayüzü tasarlama, veritabanı tasarlama, grafik işleme, hatta QA testlerine kadar.

Birincil rol yazılım / kod yazmaksa, geliştirici hangi rolleri üstlenmemelidir? Orada hiç?

Bu sorunun amacı, geliştiricinin başka bir rolü dolduramadığı için değil - ek bir rolün aslında birincil role karşı çalışması veya gerçekten program yapmayan birinin özel bir rolü olması gerektiğidir.

Sistem yöneticisi. Yazılım geliştirmek ve BT altyapısını kullanmak, dışarıdan birine benzeyen iki farklı beceridir. (Hepsi sadece bilgisayarlara çarpıyor, değil mi?) Ufacık bir şirket için, The Computer Guy'ı ofisteki tüm makinelerden sorumlu hale getirmek için cazibe çok güçlü olacaktır.

Her iki şapkayı takma becerisine sahipseniz, harika; ama bu, insanların farkettiğinden çok daha büyük bir zaman alıcı olabilecek şeylerden biri ve ilerledikçe kendi kendini öğretiyorsanız, şansınız pek de iyi değil.

İşverenin istediği şapkayı takarsın. Seni takım oyuncusu yapan da bu. Seni bir Problem Çözücü yapan şey budur .

İnsanlar "geliştirici" veya "mimar" veya "analist" olma fikrine de kapılıyorlar. Boşver onu. Sen bir problem çözücü olmalısın. Kod sadece kemerinizde bir araçtır.

Problem Çözme asla tarz dışına çıkmaz.

İşverenim teknik destek yapmamı veya bilgisayar yapmamı istiyorsa, öyle olsun. Geliştirici maaşını dikkate alarak paralarını boşa harcadıklarını düşünüyor, ancak bu onların işi. Sorunları çözmek için buradayım. Ancak bunu yapabilirim, yapacağım. Ve eğer belirli bir süre sonra, yeteneklerim boşa gidiyor veya iş tatminin olmasını istediğim yerde değil gibi hissediyorum, o zaman başka bir işe geçme hakkım var.

Ama temel soruya - giymediğiniz bir şapka yok. Heck, kahve getirmeni istiyorlarsa, yap. Onların sorunlarını çözmek; Sadece bir değişiklik arzu ederseniz başka bir iş bulma hakkına sahip olduğunuzu bilin.

Tester!

Gerekirse lütfen bize test okulundan doğrudan test gönderin!

Test ediciler olmadan insanlar her şeyin yarasadan çıkmasını beklerler çünkü programcı test cihazıdır ve çok zekidirler, çalışması gerekir.

Köpek maması iyi bir fikir değil demiyorum. Sadece programcı olduğum için test cihazlarının çok önemli olduğunu düşünüyorum.

Ofis donanımı sorunları için go-to-go olma konusunda dikkatli olmalısınız . Bu PC'de sorun giderme, sunucu yöneticisi, yedeklemeler ve hatta telefon sistemi çalışmalarını içerebilir. Önceki donanım deneyimimden bahsetme hatasını yaptım ve sonunda donanım / sorun giderme görevlerim programlama görevlerim ile ciddi şekilde çelişiyordu.

Bir programcı kendi kodu için tek test edici olmamalıdır .

Geliştiriciler bir dizi varsayımla kod yazarlar. Test edenler aynı varsayımlara sahiplerse, bu sınırların dışında beklenmeyen işlevleri kullanmayacaklar ve birçok sorun tespit edilmeden kalacaktır.

Dahası, ileriye doğru hareket etmek için, test ediciler (belki de bilinçaltı bir seviyede) durumdayken, şeyleri parçalamaya çalışmak için motive edilmemişler.

Bu, dev testinin faydasız olduğu anlamına gelmez. Oldukça zıt - iyi yazılım geliştirme testi, test edicilerin daha derin konular üzerine odaklanmalarını sağlar. Bununla birlikte, dev testi özel bir test cihazının yerine geçmez .

İki, yarasadan hemen uzak durabilirim.

1. Teknik Destek. Müşterilerin yeni site üzerinden çalışmalarına veya özellikleri nasıl kullanacaklarını öğretmelerine yardımcı olmak için burada değilim.
2. Müşterilerle sürecin çeşitli noktalarında arayüz oluşturmak gerekli olsa da, yönetici bir programcı olmadığınız sürece, onlarla doğrudan özellikler ve tasarım uygulamaları hakkında iletişim kurmamanız gerekir.

CSS / UI geliştirmenin "bölge" programlama dışında olabileceğini söyleyebilirim ama benim tecrübeme göre bugün gerekli bir beceridir. Sadece masalardan kaçamaz ve doğru şekilde uygulamak için başkasına güvenemezsiniz. Yeni bir tasarımla başa çıkmak için tasarım yapmaktan ya da kodu değiştirmekten hoşlanmıyorum, ama bu işin bir parçası.

Sorgu yazmak iyidir, Q / A testi iyidir (ve IMO programcının işi olmalı , harici bir departmana sahip olması gerekir, ancak önce test etmelisiniz). Sunucu yönetimi biraz gri bir alandır. Projenin büyüklüğüne bağlı olarak veya özel bir sunucu yöneticiniz varsa, gerekebilir veya gerekmeyebilir.

Genel olarak, çoğu programcının kullanıcı arayüzünün görünümünü ve hissini geliştirmemesi gerektiği benim deneyimlerim oldu - kesinlikle bir UI geliştirebildiğim halde (ve genellikle bir prototip veya konsept kanıtı oluştururken bir tane oluşturabiliyorum), bu İnsan faktörlerinden birine daha iyi (küçük şirketimizde, aynı zamanda ekran düzenlerini düzenleyen ve kılavuzların ve broşürlerin çoğunu yaratan bir grafik sanatçısıdır).

Ayrıca, geliştiriciler QA testini yapmamalı - bu QA departmanının işidir (çalıştığım firma gömülü tıbbi cihazlar yapar, bu yüzden testin ayrı bir bölüm tarafından yapılması şarttır).

Öte yandan, geliştiricilerin veritabanlarını tasarlayamamaları ve SQL yazamamaları için bir neden göremiyorum, eğer arka plana sahiplerse - çok defa yaptım.

Teknik Destek

Teknik destek çağrıları yaparak günümün çoğu harcanıyor ...

Bazı popüler olanlar:

• "Hesabım kilitlendi" veya "Şifremi unuttum"
• "[Telefon | klavye | fare | bilgisayar] çalışmıyor"
• "Bilgisayarım yavaş, sıra dışı bir şey olup olmadığını kontrol edebilir misiniz?"
• “Bu düğmeye tıkladığımda neden X oluyor? Y yapıyor olmalı”
• "Bu açılır pencereleri almaya devam ediyorum ...." veya "Sanırım virüsüm var"
• “Bu kişi artık burada değil, bütün eşyalarını etkisiz hale getirebilir misin?”
• "Yeni bir çalışanımız var, bunları giriş bilgileri, güvenlik kartı, telefon numarası, e-posta vb.

Kendisini yönetmesini sağlayan herhangi bir rol. Küçük takımlarda, üst düzey geliştiricilerden birini proje yöneticisi yapma eğilimi gösterir, ancak aynı zamanda onu programcı olarak da tutar. Bu her türlü soruna yol açar, çünkü bu adam bir programcı olarak temelde yönetilemez. Tüm görevlerini diğer ekip üyelerine devretmek yerine, çoğu kişiyi, özellikle de en zor görevlerini kendisine devretmek için cazip olacaktır. Bu nedenle, en çok sorun yaratabilecek olan görevler, programcı olarak sadece% 50 olan ve hiç kimseye olmayan raporlar olan bir kişiye verilir. Diğer ekip üyeleri teslim edemediklerinde, kıçlarına tekme atmak yerine, görevlerini yapmaya çalışacaklar, çünkü bir proje yöneticisi olarak, başarısından sorumludur ve bunu başarmanın en güvenli yolunun kendisi yapmaktır. değil mi?

Geliştirme, dağıtma veya bakımını yapmada elinizde olmayan ve büyük değişiklikler konusunda hiçbir eğitim almayan ve güncel tutulmayan bir şeye teknik destek. İşimin bir kısmı, internetlerinin neden çalışmadığını arayan müşterilerin telefonuna cevap veriyor. İşin bu yarısı ile ilgilenmiyorum, bu yüzden onlara kullanım için hiçbir şey söyleyemem.

Teknik destek yapmak zorunda değil, sorun yok. Bir şeyler geliştirmeye çalışırken sekreter / teknik destek görevlisi olmak.

Bütün gün şikayet eden insanları dinlemek zorunda kalmaları ve onlara hiçbir şey söyleyememeleri oldukça vergilendiriliyor. Her ne pahasına olursa olsun, bu kaçınarak tavsiye ediyorum.

Satış .

Bazı zayıf böcekler bunu yapmak zorundadır, ancak geliştiriciler olmamalıdır.

Büyüdükçe, geliştiricilerin kendi uygulamalarını yapmamalarının en iyisinin olduğunu anladım (Bu diş ve çivi ile savaştım). Seçme hakları dışında, üretim veritabanı üzerinde herhangi bir hakka sahip olmamalıdırlar. Kodumuz çok daha az hata aldı (ve aynı şey birden fazla kez kesilemedi, çünkü değişiklik yalnızca prod'da yapıldı ve daha sonra bir dev dağıtımının üzerine tekrar yazıldı, daha sonra acele, durulama ve tekrarlama sırasında prod üzerinde düzeltildi) konuşmayı diğer insanlara vermeye başlaması gerekiyordu ve dağıtım tam olarak doğru olmadığından üretim değişikliklerini hızlıca yapmalarına izin verilmiyordu. Dahası, yanlışlıkla "tablodaki her kaydı değiştiren ifadenin nerede kullanılmadığı vurgulanmadan güncellemeler" sorununu da durdurduk.

Sanatçı ve Kullanıcı Arabirimi Tasarımcısı .

Programcıların çoğu sanat yapıtlarında oldukça fakirdir, ancak şirketler bir sanatçının ürünleri için resim ve ikon çizmesi için para ödemekten zahmete girmez ve sadece "programlayıcı sanat" ı kullanır - çirkin sonuçlar ile. (Windows Vista'ya kadar, bu Mac'ler ve PC'ler arasındaki en belirgin ayırt edici etkendi - Mac'ler güzel ve arkadaş canlısı görünüyorlardı, bilgisayarlar bir göz alıcıydı)

Benzer şekilde, birçok programcı kullanıcı arayüzüyle pek ilgilenmez - öncelikle kodlarını önemserler. Basitçe üye değişkenlerinin içeriğini doğrudan düzenlenebilir alanlara maruz bırakırlar, genellikle formlarındaki düğmeleri ve alanları koydukları yere bakmazlar ve bunun yeterli olmadığını ve kullanılamaz bir yazılımla sonuçlandığını varsayarlar. (Cep telefon endüstrisi, iPhone kullanmaları güzel bir telefon kullanıcı arayüzü oluşturabileceğini göstermek için gelinceye kadar çok suçluydu.)

Lotus Notes, programcılara yardımcı olacak profesyonel bir tasarımcı almazsanız, bu ikisinin de ne kadar kötü olabileceğinin parlayan bir örneğidir.

Genel testler ve test planları yazma. Cidden, millet, kendi test planlarını yazabilirim, ancak bu, yanlış yazımları, yanlış varsayımları ve eşyaları yazarken yaptığım bilişsel hataları ne olursa olsun üründe pişirmek anlamına gelir. Çalıştığım bir şirketten nefret ettiğim tek şey buydu; Şu an bulunduğum yerde, en azından bu şeyleri yakalayabilecek kod incelemelerimiz var.

Asla makul şekilde kullanabileceğiniz ve rahat edebileceğinizden daha fazla "şapka" giymeyin, A veya B yapmamaları gerektiğini söyleyerek delik geliştiricilere güvercin vermeye çalışın harika bir UI tasarımcısının farkedilmeyebileceği anlamına gelir çünkü birileri programcıların uzak durması gerektiğini düşünüyor UI.

Günün sonunda herkes farklı güçlü ve zayıf yönlere sahip olacak ve iyi bir yönetici / süpervizör / ekip lideri yeteneklerin uygun şekilde kullanılmasını sağlamak için kendileri için çalışan insanları yönlendirmenin en iyi yolunu bilmeli. Aynı şekilde, kullanıcı arayüzü tasarlamada veya son kullanıcılarla başa çıkmada rahat değilseniz, o zaman bu alandaki rolünüzü en aza indirebilmeniz için ekibinize bildirin. Bununla birlikte, başka bir alanda ek iş almak için hazırlıklı olmalısınız.

Ayrıca, çok fazla şapka takıyorsanız (örneğin, programcı, kullanıcı arayüzü tasarımcısı, test cihazı, iş analisti, vb.), Ya bazılarında kötü performans sergileyeceksiniz ya da kendinizi yakacaksınız. Kaç tane şapka kullanabileceğinizi bildiğinizden emin olun ve iş yükünü bu seviyede tutmaya çalışın.

Bunun ötesinde, bir geliştiricinin bu rolde üstünlük kazanma becerisine sahip olması durumunda giymemesi gereken hiçbir "şapka" yoktur.

Aşağıdaki durumlarda bana atılan herhangi bir işi kabul etme eğilimindeyim:

• Beceri seviyem ve olası sonuçları hakkında şimdiden uyarıyorum ve patronum kabul edilebilir olduğuna karar veriyor.
• Beklenmeyen bir şeyle başa çıkmamda bana yardımcı olabilecek (ve muhtemelen bir aşamada olacak) guru düzeyinde bir kişi var
• Bazı belgeleri okuyun, çevrimiçi olarak sorulan sorular vb.

Bu şekilde çoğunlukla patronuma karşı sigortalıyım ve birisi yanlış giderse en azından tamir edilebilir.

Geliştiriciler durumdaki paydaşlardır (müşteriler, mal sahipleri, vb.), Bu nedenle anlamlı bir iş beklemede hakları vardır. Bence bu sizin güçlü yanlarınızla çalışma fırsatı demektir .

Dolayısıyla, bir geliştirici enerji vermeyen, kişisel gelişimine katkıda bulunan ve en yüksek performansa yol açan bir şapka giymemeli ve bunları kendileri için yapan "şapkalardan" vakit geçirmemelidir.

Kendi kodunu test eden tek kişi olmamaktan başka, şapka takan geliştirici için anlamlı bir iş olması halinde herhangi bir "şapka" nın uygun olduğunu düşünüyorum.

"Tasarımcı" ya da "yaratıcı adam". Bir sonraki çevrimiçi reklam kampanyası için pazarlama metni yazmaya veya x_x'i bilmeden önce mavinin "doğru" gölgesiyle ilgili bitmeyen tartışmalara bir uygulama arabiriminin mockup'ını masumca bir araya getirmeye devam edersiniz.

o bira kutusundaki şapka bir pipetle yan tarafta. Eğer yakalanırsan kötü bir fikir.

Düzenle:

İşte nefret ettiğim şapka ama bunun çok büyük bir ödülü var - bu bir şeyi kırarsa bütün bunların senin suçun olduğunu söyleyen büyük bir işaret ... ah, ama eğer iyiyse, o zaman sen oğlumsun hepimizin seni tanıdığı iyi çocuksun are - şimdi bodruma geri dön ... iyi çocuk ... hepsi bu.

Suçlama şapkası.