Yakın zamanda kariyerime orta ölçekli bir şirkette web geliştiricisi olarak başladım. Başladığım anda mevcut bir uygulamayı genişletme görevini aldım (kötü kodlanmış, yıllar içinde birden fazla programcı tarafından geliştirilen, aynı görevleri farklı şekillerde, sıfır yapıyla ele alıyor).

Böylece bu uygulamayı istenen işlevsellik ile başarıyla genişlettikten sonra, bana başvuruyu tam olarak sürdürme görevi verdiler. Bu elbette bir sorun değildi, ya da öyle düşündüm. Fakat daha sonra, mevcut kodu iyileştirmem ve yalnızca bir hata bildirildiğinde sadece hata düzeltmelerine odaklanmama izin verilmedi.

O andan itibaren, aynı şekilde sürdürmem gereken yukarıdaki gibi üç projem daha oldu. Uygulamayı sıfırdan yaratmama izin verilen dört proje aldım ve bunları da sürdürmem gerekiyor.

Şu anda, korumak zorunda olduğum her uygulama için kullanıcıların günlük postalarından (okuma yöneticileri) çıldırmaya başladım. Bu postaları doğrudan ele almamı bekliyorlar, ayrıca iki yeni proje üzerinde çalışıyorlar (ve bundan sonra sıralanan beş proje daha var). Üzücü olan şey, kendimi kodladığım herhangi bir şey hakkında henüz bir hata raporu almadım. Bunun için sadece arada sırada 180 derece farklı değişiklik istekleri yapalım.

Herneyse, bu normal mi? Bence bütün geliştirici ekibinin iş eşdeğerini yapıyorum.

Başlangıçta işlerin farklı olmasını beklediğimde salak mıydım?

Sanırım bu yayın büyük bir ranta dönüştü, ancak lütfen bunun her geliştirici için aynı olmadığını söyle.

Not Bir süpermarketteki kasiyerden düşük değilse maaşım neredeyse eşittir.

Benim biri sırasında staj Ben zaman yapıyor hata düzeltmeleri harcadım bulundu. Giriş seviyesi çalışan olarak, en seksi işi almayacağınızı, başka kimsenin istemediği homurdanmaya devam edeceğinizi anlamalısınız. Talihsizlik, ama her işte böyle.

Ek olarak, bir şirket için, çalışan kodun temiz olan koddan daha önemli olduğunu fark etmeniz gerekir. Şirketinizin bakış açısına göre, mevcut yapıyı değiştiriyorsanız, daha önce yapılan bir şeyi tekrar yapmaktan ve daha da fazla hataya neden olmaktan ötürü harcadığınız paradır. Genellikle bu tür şirketler bilgisayar / yazılım şirketleri değildir, bu nedenle yeterince yüksek bir yöneticinin bazen bu büyük revizyonları yapmanız gerektiğini bilecek teknik altyapıya sahip değildir. Bununla birlikte, eğer şirketiniz teknik olarak yetkin kişilerce yönetiliyorsa ve iyi kodun değerini anlıyorlarsa, bazen savaşlarınızı seçmeniz gerekse de, bir işin asıl amacı hala para kazanmaktır ).

Bununla birlikte, yazılı iz bırakabilmek ve daha anlamlı bir iş yapmak isteyen olmanızın mantıksız olduğu söyleniyor. Aynı zamanda bu kadar çok farklı yöneticiden gelen talepleri yerine getirirken aynı anda bir çok projeyle uğraşmanız da talihsiz bir durumdur.

Bir programcı olarak, başkalarının kodlarını korumak ve değiştirmek için zamandan başlayarak yazdığınızdan daha fazla zaman harcayacağınız hayatın bir gerçeğidir. Eğer bu sizin için bir sorunsa, belki hobi olarak gelişmeye devam etmeli ve farklı bir kariyer sürdürmelisiniz. Kurallara uyma konusunda sorun yaşıyorsanız, ancak etkili bir şekilde kullanılmadığınızı veya bunaldıklarınızı hissetmiyorsanız, yöneticinizle görüşmeniz gereken bir konu budur. Eğer problemleriniz bundan daha ciddi ise veya yöneticilerinizin beceri setinizi etkin bir şekilde yönetmeyi bilmediğini düşünüyorsanız, farklı bir şirkette bir pozisyon bulmayı düşünmek iyi bir fikir olacaktır. Belirtilen düşük maaşınız göz önüne alındığında, bu muhtemelen en iyi hareket tarzınızdır.

Yönetimin iş yükünüzü yönetme ve görevleri önceliklendirme gibi bir sorunu olduğu anlaşılıyor. Yöneticinizle konuşmalı ve aşırı yüklenmiş olduğunuzu anlamalarını sağlamalı ve eğer herkes sizi derhal yerine getirmek istedikleri isteklerle bombalamaya devam ederse etkili bir iş yapamazsınız.

Bu, bir görevden diğerine atlamanızı sağlar ve zihninizde çok fazla zaman harcarsınız. Etkili yazılım geliştirme çalışması için, kişi kendini bir göreve sokabilmeli ve tamamen buna odaklanabilmelidir. Kişi ne kadar fazla kesinti olursa, içerik değişimi ile o kadar çok zaman kaybedilir. Araştırmalar, aklımızın en verimli çalıştığı yerdeki suya dalmanın ve akış durumuna ulaşmanın yaklaşık 15 dakika sürdüğünü gösteriyor . Her 15 dakikada bir kesinti yaparsanız, asla sizin için ve şirket için çok büyük bir atık olan akışa giremezsiniz.

Bu nedenle , yöneticinizle daha mantıklı bir çalışma modu görüşmeye çalışmalısınız . Bu , gelen taleplere öncelik vermeyi ve bir dereceye kadar önceden planlamayı içermelidir . Tüm kullanıcı istekleri öncelik sırasına göre sıralanmış bir listede tutulmalıdır. Ve önceliklere istek sahibi tarafından karar verilmemelidir (doğal olarak herkes isteğinin dünyadaki en önemli olduğunu düşünür), ne sizin tarafınızdan değil, ancak sürdürmekte olduğunuz tüm ürün yelpazesine ilişkin yeterli iş bilgisine ve genel bakışa sahip bir kişi tarafından ( ürün sahibinin ).

İdeal olarak, gelen tüm istekler, JIRA veya Mantis gibi bir sorun izleyiciye girilmelidir . Ya da en azından ürün sahibine postayla yolladım. Ayrıca, kullanıcılardan gelen tüm şikâyetleri de "isteğim neden henüz hazır değil ?!" dediği için geliştirme işine odaklanmanıza izin vermelidir. Eğer bu elde edilemezse, en azından zamanın kesintisiz bir kısmını saklamak için gelen taleplere bakıp onlarla ilgilenirken zamanın bazı pencerelerini görüşmelisiniz.

Bu mümkün ise, bir sonraki adım bir dereceye kadar önceden plan yapmak olabilir. Yani, o zaman, öncelikli isteklerini uygulamak halinde zaman planlamak için gereken zamanı tahmin edilmektedir sprint bir veya daha fazla hafta her olabilen ve zamanınızı kapsayacak şekilde önümüzdeki sürat yeterli görevleri tahsis.

Muhtemelen, gelen acil durum talepleri için zamanınızın bir kısmını saklamak istersiniz, ancak gerisi önceden planlanabilir. Ayrıca, farklı projeler üzerinde çalışmayı ayrı "çizgiler" halinde, yani Pazartesi günü A projesi, Pazartesi-Çarşamba günü B projesi, Perşembe sabahı C projesi ve öğleden sonra D projesi vb. bağlam değişimini azaltın.

Bu şekilde önümüzdeki bir veya birkaç hafta içinde ne yapacağınız konusunda kabaca bir fikriniz olur. Ayrıca, bu müşterilerinize de bir yol haritası verir: Hangi isteğin ne zaman uygulandığını görebilirler. Buradaki menajerinize "çevik" kelimesini söylemek isteyebilirsiniz ya da istemeyebilirsiniz - bu temelde çevik bir gelişmedir , ancak bazı insanlar gerçekte ne olduğunu bilmeden çevikliğe karşıdırlar :-)

Mevcut pozisyonunuz şirketiniz tarafından düşük görünse bile , sürdürdüğünüz projeler ne kadar çok olursa, pazarlık gücünüz o kadar fazla olacaktır .

Tüm bu projeleri sürdürmek için yeni bir kiralama bulmak ve eğitmek şirket için oldukça zaman alıyor (= para). Ve haklı olarak, kodunuzun bu uygulamaların eski bölümlerinden çok daha iyi olduğunu işaret edebilir, bu yüzden aynı miktarda para için benzer yeteneklere sahip bir adayı kolayca bulabilecekleri söylenemez. Çalışma koşullarını iyileştirmezlerse, bir sonraki çocuğun bıkmasını ve sizin kadar çabuk istifa etmelerini sağlayacaklarını söylememelisiniz ... Sizi tutmanın kendi yararları olduğunu anlamalarını sağlamaya çalışın ve nerede olduğunla ilgili seni mutlu etmek :-) Bu, yukarıdaki koşulları görüşmek için biraz güç verebilir ve / veya maaş zammı talep edebilir.

Ne kadar pazarlık gücünüz var - bu büyük bir sorudur. Yönetiminiz bu fikirlere açık olabilir veya olmayabilir ve memnuniyetinizi ciddiye alacak kadar size saygı duyuyor olabilir veya olmayabilir. Ama kartlarını iyi oynarsan, şansın var. Ve eğer reddederlerse, her zaman daha iyi bir iş yeri arayabilirsin. Bu durum her başlangıç ​​için aynı değildir, ancak (ne yazık ki) deneyimleriniz oldukça tipiktir. Ama orada gerçekten daha iyi iş yerleri var . İşyerinin kalitesi sadece coğrafi konumla gevşek bir şekilde ilişkilidir, ancak benim düşüncem Kuzey Avrupa’da ortalama şanstan daha yüksek olduğun. Bu nedenle mevcut koşullarınızı belirgin biçimde iyileştiremezseniz, tamamen bıkmadan ve yanmadan hemen önce aramaya başlamanız gerekir .

Halen işiniz varken iş aramak çok daha iyidir, bu yüzden hemen paraya ihtiyacınız olduğu için ilk teklifi kabul etmeniz gerekmez. Sonunda daha iyi bir yer bulacaksınız :-)

Not Bir süpermarketteki kasiyerden daha düşük değilse, maaşım neredeyse eşittir.

Heh bunu okuyana kadar nasıl pazarlık yapılacağı hakkında bir şeyler yazmak istedim. Şimdi söyleyebileceğim tek şey bırakmak! Derecesi ile bir geliştirici genellikle kazandığı yarısı olduğunu varsayalım. Ve olayların düzeldiğini ve size hemen% 10 artış sağladıklarını varsayarsak, oraya gitmenin ne kadar sürdüğünü kendiniz belirleyebilirsiniz. Ayrıca, işle ilgili hiçbir şey öğrenmiyorsunuz ve oradaki mükemmel mühendislerle çevrili görünmüyorsunuz, bu yüzden zaman kaybı.

Ben de benzer bir durumdaydım ve o yolda kalırsanız asla bitmeyeceğini söyleyebilirim. Yönetim sana kıpırdatmaya devam edecek, çünkü ... yapabilirler.

Bu konuda sahip olduğum birkaç ek düşünce var.

1. Neyi seviyorsan onu yap. Sevmiyorsanız, sevebileceğiniz şeyi bulma girişiminde bulunmaya kendinizi hazırlayın.

2. İletişim. Gerçekçi olmayan beklentilere cevap verme konusundaki yetersizliklerinizi açıkça belirtin. Benzer tecrübelerime göre mimar (en çok kürek çeken), “başkalarının sizden beklentilerini yönetmelisiniz” dedi.

3. Tükenmişlik. Eğer tükenmişlik yaşamamışsanız, kaderi özendirmeyin. Hayatınızı ve ruhunuzu aklınızdan çıkarır. En iyi çabanıza rağmen, çalışma amacınız gri, kasvetli ve anlamsız hale geliyor. Bu tavsiyeyi veriyorum çünkü her ne pahasına olursa olsun tükenmişlikten kaçınmalısınız.

4. Eğitim. İşte gümüş astar. Eğitiminiz ve deneyiminiz, sinir bozucu ve belki de düşük ücretli olmasına rağmen, aslında, kariyeriniz için çok değerlidir. Bu, bunu gerçekleştirmek için tasarruf lütufunuzdur, çünkü mümkün olduğunca fazla öğrenmeyi emebilir ve kaçınılmaz cam tavanları geciktirebilirsiniz.

Hangi yetenek ve becerilerinizi geliştirdiğinize odaklanın ... Bunlar sizi kariyerinizin bir sonraki fırsatlarına taşıyacak.

Burada birden fazla meseleyle uğraşıyorsunuz ... En bariz olanla başlayalım ...

Bu normal mi?

Cehennem hayır. Ama ... yaygın mı? Ne yazık ki evet.

Hata Düzeltme Hayal kırıklığı ile ilgili olarak

Bu, başa çıkmak zorunda olduğunuz karışıklığın geri kalanını ve sizi içine alan birçok projeyi mazeretsiz kılmasa da, sadece bir "hata düzeltme" uygulamasının sadece bir geliştirici olarak sizi rahatsız ederken yaklaştığını not etmek istiyorum. , şirket ve yönetimi için kusursuz bir yaklaşım olabilir.

Daha Fazla Hata ve Maliyet için Yüzey

Ne kadar çok tuşa basarsanız, niyetimizi iyileştirmek isteseniz de böcekleri o kadar fazla tanıtma olasılığınız o kadar fazla olur. Bu, uzatılmış dev zaman, test zamanı ve maliyet anlamına gelir. Ve eğer orta ila yüksek kusurlu bir servis tahliyesine kayıyorsa, bu onlar için büyük bir karmaşa.

Kayıtlarınızdaki Gürültü / Sis

Bir SCM perspektifinden bakıldığında, doğrudan bir servis yayınının şubesinden çalışıyorsanız ve hata düzeltme ile ilgili değişiklikleri net bir şekilde görmek istediğinizde bir anlam ifade eder. Belki de 1 satırlık bir kod değişikliğini gerektiren bir düzeltmeyi çevreleyen binlerce değişikliğin olduğu 15 iş varsa, bu biraz can sıkıcıdır.

Dolayısıyla, yeni bir işe alım olarak, sizden yazılımı yeniden düzenlemekten ve / veya geliştirmekten kaçınmanızı istemek daha mantıklıdır ve benim açımdan hata düzeltmelerinizde olabildiğince "cerrahi" olmanız oldukça mantıklı. Sadece baş ağrısını uzak tutar.

Bu konuda bir şeyler yapabilir misin?

Şimdi, bu, söz konusu kişilerin zihinlerinin hem kodunun hem de akıl sağlığına ulaşmanın yolları olacağı anlamına gelmez. Küçük olmaları durumunda, biri değişikliklerinizi gözden geçirmeli, özellikle de düzeltmeleri yapmalı ve hizmet yayınlarına girmeden önce onayladıklarından emin olmalıdırlar. Bu, radikal değişiklikleri önler veya sınırlar ve daha güvenli olur.

Cehennemden Gelen Proje

Bok Kodu, Programcı Sürüsü, Çoğaltma, Bok Mimarisi

Yine, şeytanın savunucusu burada, ama sadece ilk isteğinizin birkaç sonuç vermeyen bit içerdiğini gösteriyorum.

Demek istediğim şudur: Gerçekten çok nadiren bu durumda olmayan bir kod tabanını devraldım. Yaptığım şanssızlık üzerine, son zamanlarda güzel yıldız programcıları tarafından başlatılan projeler ya da prototipler başlatıldı. Ancak şaşırtıcı derecede büyük bir çoğunluğu boka benziyordu ve bunların korkunç bir kısmı gerçek boktandı. İyi ya da iyi programcılar tarafından başlatılanlar bile, zırvalar, son tarihler ve diğer anlaşmalar gibi sonuçlanabilir.

Gerçek hayattaki endüstriyel yazılım mühendisliğine hoş geldiniz!

Ve neyin eğlenceli olduğunu biliyor musun? Web geliştirme dünyasında genellikle daha kötüdür. Keyfini çıkarın! :)

Çok Fazla Proje ve İstek, Yeterli El ve Zaman Değil

Sorun muhtemelen burada yatıyor:

• yönetiminiz (belki bilinçsizce) sizi suistimal ediyor ,
• meslektaşlarınız (belki bilinçsizce) sizi taciz ediyor ,
• senin (belki de bilmeden) kıçını örtmemek ve savaşlarını yeterince yapmak .

Yöneticileriniz yönetecek çok fazla proje üzerinde çalıştığınızın farkında olmalıdır. Olmazlarsa, en kısa zamanda olduklarından emin olun. Ayrıca onların parkta bir piknik olmadığını ve kendinizi baskı altında hissettiğinizden ve durması gerektiğini bildiklerinden emin olun.

Etrafınıza bir göz atmaya çalışın ve meslektaşlarınızın sizinle doğrudan daha fazla görev ve proje saptırmadığından emin olun (gerçekten "X bununla ilgilenebilecek") ya da dolaylı olarak ("Ben doğru kişi değilim bu, başkasını bul "-> senin olman biter).

Buradaki kişisel fıkra: Birkaç yıl önce staj yaptım ve son günümde, değerlendirmemi aldığımda, patronum, genel olarak yaptığım işten memnun olmasına rağmen , yöneticilerden birinin hissettiğini söyledi. Onları almamı beklediklerinde , başka bir stajyerde "çok eğlenceli olmayan görevler" alıyorlardı. Ben edildi mahcup onları üzdüm hissetti sahip ve fikri ben ne zaman, tembelleştiği gibi olmazdı Niyetim tam tersi oldu: Ben zor görevler kapmak ve daha az saçlı diğer genç stajyer anlaşma çalışıyordu toplama sorunları. Çok azının farkındaydım, pozisyonunda olsaydım, meydan okuma eksikliğinden sıkılırdım ve muhtemelen onun yaptığını hissettim. Mesele şu ki, hiç kimsenin 3 farklı şey hakkında yanlış varsayım yapmadığından emin olmak için iletişim kurmanız gerekiyor:

• ne yapabildiğini ,
• Yapmak istediğiniz şey ,
• ve ne yapmak istediğinizi .

Bu yüzden kısmen bu şekilde olmasına izin vermek sizin suçunuz. Ama bu normal, herkesin öğrenmesi gereken bir ders. İki harflerle tutar: N - O .

Genelde daha uzun ama çok fazla ücret karşılığı olmayan bir cevap için ön ek olarak kullanıyorsunuz: Hayır, bunu yapamam. Hayır, bunun nasıl yapıldığını bilmiyorum. Hayır, bunun için doğru kişi olduğumdan emin değilim. Hayır, bunu hiç yapmadım.

İlk başta, sadece "evet, (sonunda) yaparım" diyebilir ve bir şeyler biriktirip bitirmelerini sağlayabilirsiniz, belki de fazladan saatler ekleyerek. Çok yanlış. Zamanınızın, yeteneklerinizden sonra, sizin ve şirketiniz için en değerli varlığınız olduğunu anlamanız gerekir. Yanlış kullanılırsa projeleri, son teslim tarihlerini ve bütçeleri etkiler . Kadar basit.

Ayrıca, rapor vermeniz gereken çok fazla insanın olması endişe verici görünüyor. Başa çıkmanız gereken birden fazla müşteriniz ve iletişim kurmanız gereken birden fazla proje sahibi veya hatta ana paydaşınız olabilir. Ancak, genel olarak, özellikle yeni bir işe alım yaptığınız için, çoğunlukla yalnızca birkaç yöneticiye (ve muhtemelen sadece doğrudan yöneticinize ve muhtemelen lider veya kıdemli bir geliştiriciye) rapor vermelisiniz. Bu nasıl oldu? Bilmiyorum. Şirketinizde örgütsel bir sorun olabilir veya sizin bir iyilik yapıp doğrudan iletişime geçmenizin ve "hayır" dememesinin sonucu olabilir. Veya doğrudan yöneticiniz, bildiğim kadarıyla, gönderme görevleriyle ilgili sorunlar olarak olabilir (gerçekten tahmin ediyorum, ancak kalıp tanınabilir ve tanınır).

Aşağıdakileri hızlı bir şekilde yapmanızı öneririm: doğrudan yöneticinizle şahsen konuşun, diğer yöneticilerin biraz saldırgan olabileceğini veya çok fazla kişiden gelen çok fazla şeyin olduğu konusunda muhtemelen sızlanabileceğini açıklayın ve hangisinin önceliklendirileceğini bilmek için onun girdisine (ve muhtemelen onlarınki) ihtiyacın olduğunu.

180 derece Değişim İsteği

Bunlar bir başka büyük sorun. Muhtemelen senin hatan değiller, ama bu sorunu çözmelerine yardım edebilirsin.

"180 derecelik değişim talepleri", sizin için güzel ve doğru bir şekilde adlandırdığınız gibi , gereksinimlerin başından beri belirsiz olduğu ve zaman içinde hiç kimsenin onları kesmesi ve temizlenmesi için yeterince çaba göstermediğinin açık bir işaretidir .

Bu genellikle birisinin telefona (veya daha iyi bir şekilde ayaklarına) bakması ve paydaşları elinden tutup onlara açıkça söylemesi gerektiğinde: “bulunduğumuz yer, gitmemizi istediğin yer, onayladığımızı onaylıyor musun? doğru yöne mi gidiyorsunuz? " Başlangıçta net cevaplar alamama sorun değil, ancak zaman geçtikçe, daha net olmaları gerekir, ya da bu proje gerçekleşmeyi bekleyen bir felaket.

Genellikle tüm paydaşları ulaşabileceği bir yerden tut, bir odaya koy, onları sorunlu meselelerden geçir ve artan bir şekilde bunları çözmeye çalış - ve bu işteyken öncelikleri bulmaya derim. Ancak, sizin durumunuzda, bu zaten yapmak için çağrı olabilir. Ama sizden, projelerin sorumluluğunu size gerçekten verdiklerini söylersiniz; öyleyse gerçekten durum buysa, o zaman sorumluluk al ve bunu yap. Üstelik "Bunu yapamayız" , hatta "biz yapmayacağız" demekten de çekinmeyin . Bir projenin kapsamını sınırlamak gerçekten önemlidir.

Kapsam yoksa, tartışmanın sonunda kesin şartlar yoktur.

E-posta Aşırı Yüklemesi

İnsanlar, kullandıkları iletişim ortamına bağlı olarak farklı davranma eğilimindedir. Şahsen, oldukça konuşulan biri olsam da (ve çoğunlukla yabancı ülkelerde çalışıyorum, bu yüzden telefonda çok fazla konuşmayı sevmiyorum), verime dayalı tercih sırasını tercih ederim:

• insanlarla yüz yüze konuşmak ,
• Telefondaki insanlarla konuşmak,
• Sohbet yoluyla insanlarla konuşmak,
• e-posta yoluyla insanlarla konuşmak.

E-postalar, not almak için onay almak, takip etmek için iyidir.

Problemli noktaları planlamak, planlamak ve tartışmak için işe yaramazlar. Açılana kadar erkeğin kapısını çalın ve şeyleri netleştirmek için bir not defteri ve belgelerinizin bir kopyasını kullanarak oturun. İşiniz bittiğinde, bir e-posta gönderin ve onayınızı isteyin. Olumsuz bir cevapla ya da zarfa başka bir şey sokmak için gizlenmiş bir teşebbüsle geri gelirse, tekrar konuşmacının ofisinin kuşatılmasını sağla.

Bu yazılım mühendisliği. Bir klavyede yazı yazmamanız daha verimli olur ve aslında başa çıkmanız gereken pisliği kesin olarak azaltabilir.

Bir Takımın Çalışmaya Değer Yapması

Bir takımın işe değerine eşdeğer mi yapıyorsun? Olabilir.

Takımınızın işe değerinin eşdeğerini yapıyor musunuz? Muhtemelen değil.

Demek istediğim, takımınızın muhtemelen çalışmakla meşgul olduğu ve çok çalıştığınız. Ve mesele şu: mevcut proje zaman çizelgelerinin dışına itilmesi gereken ya da ellerinde zamanı olan birine verilen şeylerle aşırı yüklüyorsunuz.

Başlangıçta işlerin farklı olmasını beklediğimde salak mıydım?

Hayır; Sadece parti için yeni. İlk takılma ya da ilişki gibi. Üstesinden geleceksin.

Sanırım bu yayın büyük bir ranta dönüştü, ancak lütfen bunun her geliştirici için aynı olmadığını söyle.

Bu, kaotik organizasyonlardaki her geliştirici için, başlangıçlar veya iyi kurulmuş devler olabilir ve ölçeğin sağ tarafındaki hayatta kalma şansınızı belirtmek için bir şeyi hareket ettirmek için hiçbir deneyime veya güvene sahip olmadan aynıdır.

Not Bir süpermarketteki kasiyerden daha düşük değilse, maaşım neredeyse eşittir.

Berbat görünen işlerde iyi maaşlar yaptım. Önemli olan çek üzerindeki sayı değil, bağlam. Ne yaparsın, yaşın, yaşadığın ve çalıştığın yer vb.

Olduğu söyleniyor, eğer çok az para alıyorsanız, çok çalışıyorsanız ve tamamen küçük değilseniz, bu zammı isteyin ya da yeni bir iş bulun!

Basit:

• Yaptıklarına değer verirlerse, zam yapmayı memnuniyetle kabul ederler.
• eğer yapmazlarsa, bu şirkette gelecek çok pembe görünmüyor (en azından sizin için önemli olan sizin için), bu yüzden ayrılmak konusunda kötü hissetmeyin.

Zam soran unutmayın olduğunu ilk başta öyle düşünmeye enclined olmaz olsa bile, iyi bir şey. Yaptığınız şeyleri takip ettiğinizi kanıtlar ve hala gemide kalmaya istekliyken diğer seçeneğe göz kulak olduğunuzu gösterir. Ve iş görüşmeleri veya genel olarak pazarlık gibi oldukları için, onları istemeye alışmak iyi bir şeydir: pratik gerektiren bir şeydir ve eğer kendiniz için ulaşmazsanız gökten düşmezler. Bazı şirketler, talep edilmeksizin düzenli olarak zamları dağıtacaktır, ancak bunun nedeni yalnızca sizi yarı mutlu ve daha az istekli tutmaya devam edeceğini bilecek kadar akıllı olmalarıdır ve çimlerin ayağınızın altında kesilmesini istedikleridir (çoğu insan biraz daha doğrudan teklif ettikleri zam teklifini yükseltmek konusunda biraz tedirgin).

Bu talebe nasıl devam edileceği, buradaki BU proje kapsamı dışında, bu yüzden ayrıntılara girmeyeceğim. Ancak, SCM taahhüt kimliğinizin, sabit hatalarınızın ve başarılarınızın bir kaydını hazırlamanızı ve bunları ekibin genel çabasıyla karşılaştıran raporlar hazırlamanızı öneririm. Bu yoldan:

• akranlarından çok daha fazlasını yaptıysan veya yapmasan da, kendin için ölçebilirsin ,
• İsteğinizin gerekçeli olmadığını söylerlerse zeminine dayanabilirsiniz .

Diğer kişilerin yorumlarına ek olarak:

1. Evet, giriş seviyesi çalışanlarına başkasının yapmak istemediği işleri vermesi normaldir.

2. Bunu gelecekteki kariyeriniz için bir yapı taşı olarak görmelisiniz.

Peki ne yapmalısın? Kendinizi profesyonel bir geliştirici olarak kanıtlamak için, çalışmanızın yapılandırıldığından ve planlandığından emin olmanız gerekir, aksi halde şu anda yaptığınız iyi şeyleri inşa etmeyi zor bulursunuz; sen zaten değilsin).

1. Her proje için çalışmanızı doğru bir şekilde kaydedin. A projesinde bir hatayı düzeltmek için bir saat harcıyorsanız, bu kez giriş yapın. İş yüklerini tartışmak istiyorsanız yöneticinize göstermek yararlı olacaktır.

2. Birim testleri yaz. Yaptığınız projelerden bazılarının hatalarla dolu olduğunu söylüyorsunuz, bu yüzden tahminimce (eğer varsa) birim testleri var. Her bir hata raporu için, hatayı kopyalayan bir birim testi yazın ve ardından hatayı düzeltin. Bu, hiçbir gerilemenin gerçekleşmemesini sağlamaya, kodun kalitesini iyileştirmeye yardımcı olur ve eğer şansınız varsa, kodu yeniden gözden geçirmek için bir platform görevi görür (örneğin, paydaşları bazı parçaların yeniden yazımın iyileşebileceği konusunda ikna etmenize yardımcı olabilir) ünite test paketi nedeniyle yeni hatalar vermeden kalite).

3. Yeni bir iş arayın - bir çok projede aynı anda çalışıyorsunuz, sıfırdan kod yazıyorsunuz ve muhtemelen tüm proje yaşam döngüsünü deneyimliyorsunuz - bunların hepsi başka bir yerde başvuru yapmak için iyi deneyimler.

Durumunuz biraz sinirli, ama yine de normal. Ama bununla başa çıkma şeklin çok kötü. Yapman gerekenler işte burada:

• Patronunla yüzleşmeye çalış. Kötü kod tabanının gerçekte ne kadar zaman alacağı konusunda bazı kanıtlara (numaralara) sahip olmalısınız. Teknik borç gibi şeyleri anlamıyorsa, söylemeyi bırak. Kafanı mahveder ve sen de 'kötü bir davranış' adamı olarak işaretlenebilirsin. Patronuna işini yapmasını öğretmek senin işin değil.

• Kendi birikiminizi (kanban) koruyun. Yeni görevler geldiğinde sonunu koyun ve tahmini tamamlanma zamanını söyleyin.

• Tepki sürenizi arttırın, e-postanızı günde iki kez kontrol edin. Genellikle öğle yemeğinden önce ve hemen ayrılmadan önce. (E-postayı kontrol etmek, kodunuzu izlememelidir, çünkü başınızı mahvedebilir).

• Her görevin bir parçası olarak küçük kod geliştirmeleri yapın. Kullanmakta olduğunuz kod, beceri ve araçları geliştirmek sizin işiniz. Aynı zamanda uzun vadede ahlaki değerinizi artıracak.

• Gün boyunca proje değişikliği yok. Bugün sadece X projesi üzerinde çalışıyorsunuz ve Y için başka bir işe yarın başlayacaksınız.

• Kapı bekletme için günde bir saat tahsis edin. Yapması önemsiz olan küçük işler anlamına gelir. Bu görev 10 dakikadan uzun sürerse (neden ne olursa olsun), biriktirme listesine girer ve yöneticiye erteleneceğini bildirirsiniz.

Şimdi zor kısmı geliyor. Şu anda yöneticiler birbirleriyle iletişim kurmuyorlar ve sadece kendi projelerini maksimum öncelikle bitireceğinizi varsayıyorlar. Bu, kafanıza çok fazla stres getiriyor, çünkü tartışmaların ortasındasınız. İşlerinizi koordine etmeye başlamak için yöneticileri zorlamanız gerekir. Sonunda güzel ve basit bir birikiminiz olmalı ve yöneticiler siz olmadan birbirlerini zorbalık etmelidir.

O zaman bazı basit rol oynamaları yapalım. Üç yönetici ve proje vardır (X projesiyle Xavier, Y projesiyle Yvonne ve Z projesiyle Zed). İki hafta, X için 5 gün ve Y için 5 gün biriktirme hakkınız var

• Z senden bazı görevler yapmanı istiyor (1 gün)
• Bunun 11 gün içinde yapılacağına cevap veriyorsunuz.
• Z, basit bir görev olduğunu ve bir günden fazla sürmemesi gerektiğini söyler (Z'nin küçük baskı uyguladığına dikkat edin).
• Şu anda X için çalıştığınıza ve Z için ikincisine yanıt verdiğinize yanıt veriyorsunuz. Bundan sonra onun çalışmasını yapabilirsiniz.
• Z, görevini nasıl olsa hemen yapman gerektiğini söyledi (artan baskı, X ve Y topraklarının doğrudan ihlali).
• Görevini yapmanın X ve Y için çalışmayı geciktireceğine cevap veriyorsunuz. Önce onlara sorması gerekiyor. Siz de CC X ve Y.

Şimdi iki ucu var:

• Yöneticiler birbirlerine havlamaya başlayacak, birçok e-posta, muhtemelen bazı toplantılar ... Uzak durmalı ve kazananın size bir görev vermesine izin vermelisiniz.

• Hiçbir şey olmayacak, Z size görevinin nerede olduğunu iki gün soracak. Şu anda X için çalıştığınıza cevap veriyorsunuz ve Z projesi hakkında hiçbir şeyden bahsetmedi. Again CC X.

Şimdi bu tür davranışlar sizi kovabilir. Fakat durumunuz sürdürülemez ve muhtemelen bir an önce ayrılacaksınız. Bu çözüm yalnızca yöneticiler birbirleriyle rekabet ederse işe yarar (çok olağan). Ayrıca, birisinin şikayet etmesi durumunda gevşettiğinizden dolayı çalışmalarınızın (iş listesi) kaydını tutmalısınız.

Yedi yıl önce bir süredir% 100 bakım çalışmaları yapıyordum ve bunun hakkında bir makale yazdım: Bakım Programları Sanatı . Yararlı bulabileceğiniz bir bölüm:

1. Beğen

Birisi bakım programlamasını nasıl ister? Geliştiriciler ekiplerinde baş mimar olmayı hayal ediyorlar ve mevcut yazılımı sürdürdükleri zaman neredeyse bir ceza gibi geliyor. Olması gerekmiyor: bakım programlamasının kendi zorlukları vardır ve çok fazla yaratıcılık, uyarlanabilirlik, sabır, disiplin ve iyi iletişim gerektirir. Kariyeriniz için de iyi olabilir: özgeçmişinizde “Architected n 7/24 kurumsal uygulama” gibi bombalama girişleri yapmak güzel görünüyor, ancak işverenler aslında sorunları çözen kişilere değer veriyor; ve bakım programlaması, problem çözme becerilerinizi göstermeniz için iyi bir şans olabilir.

Sorununuz, hakkında daha sık duyduğunuz bir ses gibi geliyor. Günlük WTF'e kolayca sığabilecek bir iş gibi görünüyor .

Bir çok kuruluş, kaliteye göre daha fazla satış veya özelliğe odaklanmaktadır. Bu şirketlerin göremedikleri şey, bir yazılım parçasının dış özelliklerinden daha fazlası olduğudur. Ward Cunningham teknik borç terimini icat etti .

Ayrıca Steve McConnell'i teknik borç konusunda okumak isteyebilirsiniz . Bazı ilginç noktaları var. Bir Google Teknik Konuşmasında Ken Swaber , çevik yazılım geliştirme hakkında konuşuyor . İyi bir bölüm seninkine benzer bir hikaye hakkında. Çeşitli programcılar tarafından 10 yıl süren programlamanın ardından herhangi bir yeniden düzenleme yapmadan "beyin fırtınası" olan bir yazılım projesi hakkında konuşuyor . Bence bu videoyu görürseniz tarif ettiğinize çok benzerlikler göreceksiniz.

Herhangi bir yazılım sistemi genişletildiğinde kalitesi düşecektir. Aslında survice için bunu yapmak zorunda kalacak. Lehman Yasalar oldukça iyi bu ilkeyi açıklar. Sonunda şu soruyu kaybedecek: "Patronunuzu yeniden yapılanmaya yapmaya nasıl ikna edebilirim?" .

Benzer bir soruna nasıl yaklaştım:

• Patronumla yüzleştim ve geliştirmeye devam ettiğimizde kod kalitesinin düştüğünü açıkladım ( Lehman Kanunları ).
• Patronuma teknik borç kavramını açıklamaya çalıştım . Ve çalışmanıza izin vermesi, uzun vadede ona paraya mal olacak bir yoldur.
• Ona sorunun ne kadar şiddetli olduğunu göstermek için (kendi zamanımda) statik kod analizi yaptım. Patronlar yazılımı anlamıyorlar, ancak rakamları anlıyorlar. Kod ölçümlerinin kusurları olsa da, hakkında konuşabileceğiniz ölçülebilir bir şeyin olması iyidir. Bu ölçümler için normal değerlerin ne olduğunu bulmaya çalışın ve bunu kendi kod tabanınızla karşılaştırdığınızda şaşıracaksınız.
• Eğer hiçbir şey yardımcı olmazsa ve hiçbir şey değişmezse, yapabileceğiniz tek şey, belirli bir yeni özelliğin kod tabanınızın diğer kısımlarının yeniden çalışılmasını gerektireceğini açıklamaktır. Eğer yinelenen kodunuz varsa ve bir değişimin maliyetinin de çoğaltacağı bir şeyi değiştirmek istiyorlarsa açıklayın.
• Bir önceki noktaya verilen ortak cevap, hiç kimsenin istemediği ve bu nedenle bu çalışma için ödeme yapmadığı yönünde olacaktır. Bu "belki de" bu çalışmanın gereksiz olduğunu. Yazılımın daima değişmesi gerektiğini açıklamanız gerekecek. Gibi Lehman Kanunlar demek; kullanımda kalabilmek için değişmesi gerekecektir. Aksi takdirde, değişiklik yapan diğer programlar her zaman geçerliliğini yitirir. Değişimi bekleyenler ve hayatta kalacak değişime uyum sağlayabilenler. Bu nedir çevik yazılım geliştirme tüm ilgili. ( Wikipedia )

Patronum bugünlerde müşterilerimize bazen oluşturduğumuz yazılımın parçalarını yeniden düzenlememiz gerektiğini açıklamak için teknik borç kavramını kullanıyor. Sadece bunu kanıtlamak için - makul bir patronunuz varsa, işleri daha iyi hale getirmek mümkündür.

Karşılaştığınız durum, neredeyse hepsi için olmasa da çoğu kişi için aynıdır.

Bu, kariyerin ilk aşamalarında olur. İşin püf noktası: Bu sorunun üstesinden gelmek ve şirkete verdiğimiz değeri kanıtlamak zorundayız (orta ölçekli veya ÇUŞ ). Koşulların bizden ne yapmamızı talep ettiği konusunda kararlar alabilmeliyiz. Bu nedenle, işinize çaba göstermenin, bunun için fark edilmeniz ve işiniz için bir birey olarak durmanız şartıyla, hiçbir zararı yoktur. Eğer değer, şirket fark edecek! Adios ve iyi şanslar.

Bana göre yeniden yapılanmayı yasaklayan bir şirket için çalışmaya değmez. Yeniden düzenleme, önemli bir yazılım geliştirme becerisidir ve sürüm kontrol araçları, 'gövdeyi' bozmadan izolasyondaki değişiklikleri geliştirmeyi çok kolaylaştırır (bir yeniden düzenleyicinin bir şeyi kırması durumunda ). As Bob amca diyor (aktarılan): "Sen profesyonel olmak ve işinizi doğru yapmak için sormamak sahip olmalıdır."

Bakım programlaması hiçbir zaman hatalı kodları sürdürmek anlamına gelmemelidir.

Bu e-postayı beş yıl önce arkadaşımdan birinden aldım.

Email body:    

Yeni katılan bir stajyer mühendis, patronuna "Değerlemenin anlamı nedir?"

Patron: "İstifa dilinin anlamını biliyor musun?"

Stajyer: "Evet yaparım"

Patron: "Öyleyse bir değerlendirmenin istifa ile karşılaştırarak ne olduğunu anlatayım"

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Stajyer: "Evet patron yeterince, şimdi geleceğimi anladım. Bir değerlendirme için istifa etmek zorunda kalacağım ... !!!"

Yerinde olsam, işten geçtikten sonra mesai saatini ücretsiz olarak yeniden inşa ederdim. Muhtemelen eğlenceli bir iş olurdu. İşini bitirdiğinde patronuna göster. Eğer çalışırsa ve üzerinde bakım yapıyorsanız endişelenecek bir şeyleri olmamalıdır. Bu, işinizi çok daha kolay hale getirecek ve şirketteki potansiyelinize daha yüksek seviyelerin gözlerini açacaktır.

Tam zamanlı bir üniversite öğrencisiyim, yarı zamanlı stajyerlik 10 ABD Doları karşılığında çalışıyorum. Sıkıcı, tekrarlayıcı ve kolay QA işleri yapıyorum. Kendimi çok şanslı hissediyorum, çünkü bir gün bunun daha büyük ve daha iyi yerlere kapı açacağını biliyorum.

Evet, hem sizin hem de diğer kişilerin yazdığı uygulamaları sürdürmek zorunda kalacaksınız. Bunun tek istisnası, hiçbir zaman bakım gerektirmeyen bir program yazmanızdır. Bu yüzden bakım konusunda iyi olsanız iyi olur.

Yaklaşımınızdaki bir kusur sorusunda ince bir ipucu olduğunu düşünüyorum. Diğer bir deyişle, hataların giderilmesi kod geliştirmeyi gerektirmez.

Fakat daha sonra, mevcut kodu iyileştirmem ve yalnızca bir hata bildirildiğinde sadece hata düzeltmelerine odaklanmama izin verilmedi.

Birinin size "kodu geliştirmeden hataları düzeltmeniz gerektiğini" söylediğine inanamıyorum. Bu zor hem de ve imkansız. Yapamayacağınız şey, var olan kod tabanında kullanılan yaklaşımı beğenmediğiniz veya anlayamadığınız için uygulamayı yeniden yazmak.

Benim tavsiyem refactor öğrenmek. Bir hatayı düzeltirken, kodun en azından bir kısmını iyileştirme şansınız olur. Kod tabanının ne kadarının refaktörleştirileceği, hatanın ne olduğuna ve kodun ne kadar iyi veya kötü olduğuna bağlıdır. Ancak hataları düzeltiyorsanız ve bilerek kod bırakmak her yerde kokuyorsa , o zaman işinizi yapmıyorsunuz ve teknik borç oluşturuyorsunuz .

Bazı hatalar aslında sadece yeniden yönlendirme ile giderilir ve bazen kodu anlamanıza yardımcı olmak için yeniden yönlendirme yapmak yararlı olabilir . Bunun nedeni, yeniden yapılanmanın, yönetilebilirliği ve kodun tutarlılığını geliştirmesi gerektiğidir.

Bir hata düzeltmeyi tahmin ettiğimde, genellikle büyük bir refraktörün bunu yapmanın en iyi yolu olup olmadığına karar veririm ve bunu dikkate alırım. Birim testleri ile aynı. Her ikisi de, kod yazma biçiminizin bir parçası olmalı, ekstra zaman gerektiren isteğe bağlı bir şey değildir.

Öyleyse, "hatayı düzeltirken kodu geliştirebilir miyim?" Çünkü yine de olmalısın. "Hatayı düzeltmek için refactoring kullanabilir miyim?" Diye sormamalısın. Çünkü uygulamanın bozulmasına neden olan kodun yeniden düzenlemeye cüret etmesi gerekiyorsa, yine de yapmalısınız. "Bu hatayı düzeltirken birim testleri yazabilir miyim?" Diye sormamalısınız. Çünkü hatayı düzeltmeye çalışmadan önce bir regresyon testi yazmalısınız.

Not: Bu cevabın bazı niteliklerinin Jeff Atwood'a gitmesi gerektiğini düşünüyorum.

Bu bir bütün para ile ilgili. Tahminime göre, başlangıç ​​olarak, zaten ödediklerinden daha fazla kazanmış olan müşteriler için muhtemelen çok kibarsınız.

Yeni istekleriniz için fiyat teklifi almayı öğrenin. Bu kolay olmaktan uzak ve müşteriler sık ​​sık sizi deneyecek. Mümkünse deneyimli bir proje / ürün müdürünün yardımını alın.

Para açısından düşündüğünüzde, yönetimle iletişim kurmak çok daha kolay hale gelir. Mevcut müşterileriniz tam zamanlı para sağlıyorsa, yeni projeler almamalısınız. Ancak, yönetimin sizi onları yapmaya zorlamaya çalışacağını anlayacaksınız.

Eğer şirket için gerçekten değerliyseniz, pazarlık gücü kazanırsınız. Onlardan daha fazla insan işe almalarını, daha az yeni proje almalarını, bakım yükünü azaltmanıza veya maaşınızı artırmanıza yardımcı olabilirsiniz.

İşvereninizin, mevcut kodu iyileştirmenizin yasak olduğu ölçüde sizi mikro yönetmesi kararı olmamalıdır. Kendi profesyonel kararını kullan. Çalışmayı tahmin ederken, gelecekteki üretkenliği artıracaksa, bazı refactoring işlemlerine izin vermek için ek süreyi hesaba katarım.

Her neyse, işverenle etkili bir şekilde iletişim kurmuyor gibi görünüyorsun.

1. Yeniden yapılanmanın paradan tasarruf edeceğine dair kanıtınız var. Bir yeniden yapılanma projesi için bir öneri taslağı hazırlayın ve işletmenin ne kadar zaman ve paradan tasarruf edebileceğini gösterin. Kodda hangi değişiklikleri yapacağınızı ve ne kadar süreceğini tam olarak ana hatlarıyla belirtin.

2. Kodlama, toplantı ve e-postaları yanıtlamak için ne kadar zaman harcadığınızı kaydetmek için doğru bir kayıt tutunuz. Programın gerisinde kaldığında bu sizi koruyacaktır.

3. Yavaşlatmak. Bu biraz sezgisel görünebilir, ancak zamanınız ancak hızlı bir şekilde her şeyi yaparsanız kötüye kullanılacak. Daha az yaparsanız, insanlar zamanınıza daha çok saygı duyacaklar. Örneğin, e-postayı günde yalnızca bir veya iki kez kontrol ederdim. Aksi takdirde, tükenme riski vardır.

4. Ücretinizi göz önünde bulundurarak, başınızı ağrıtmaya değmez. Her gün zamanında ayrıldığından emin ol. İlave ücret ödemeden fazladan saatler koymayın. Bunun istisnası, iyi ilerleme seçenekleri varsa veya şirketin itibarı özgeçmişinizi büyük ölçüde artıracaksa, onu emmek zorunda kalacaksınız.

Daha fazlasını bilmeden, sadece yöneticilerinize daha açık olmaya çalışmanızı öneririm. Belki görev tahminlerini arttırmaya başlayabilirim. İş yükünüzün ne kadar meşgul olduğunu sürekli olarak onlara hatırlatın. Ayrıca, patronunuzla görüşmeli ve önümüzdeki altı ay içinde maaş artışı istediğinizi açıklamalı ve bu ücret artışını elde etmek için performansınızı nasıl artırabileceğinizi sormalısınız.

İyi şanslar.

Tecrübelerime göre akademik dünya ya da teknoloji odaklı bir başlangıcın ilk 6-12 ayı, gerçek bir boş sayfa ile karşılaşacağınız sadece iki güvenilir alandır. Her ikisi de kendi maliyetlerini taşırlar ancak kodlamayı seviyorsanız ve sık sık vahşi doğada öğrendiğiniz kodun kalitesi yüzünden dehşete düşüyorsanız, kariyerinizi bu yönlerden birinde göstermeye başlamalısınız.

İşverenlerinizle konuşmayı deneyin ve bunu çözüp çözemeyeceğinizi görün. Bu konuda kafanın üstünde gibisin ve kötü bir programcı olmakla alakası yok gibi geliyor.

Küçük web şirketleri aynı anda birçok projeye sahip olma eğilimindedir ve bu da sizi birçok yönden düşündürür. Ya durumundan en iyi şekilde yararlanmaya çalış, ya da eğer istersen yeni bir iş bulmaya çalış. Söz veriyorum, orada daha iyi kodlama işleri var, o yüzden bunun birisinin seni korkutmasına izin verme.

İyi şanslar ve umarım hem siz hem de çalışanlarınız yerçekimini veya çabalarınızı anlar!

Kişisel deneyim

Buradaki çoğu kişi gibi durumunuzu da tanıyorum. Temel olarak ilk kodlama işimi düşük maaşla aldım ve zayıf bir yapıya sahip bir sürü yerleşik kod sağlamak zorunda kaldım. İlk başta yeni şeyler öğrenmeyi komik buldum, ama sonunda, sürdürecek çok sayıda projem vardı, yeni projeler yapacak ve her gün daha da büyüyüp büyüen beyaz tahtalar, fark etmedim. işe yaramadı.

İki yıl dayandıktan sonra, birkaç ay sonra bana çok uyan başka bir kodlama işinden ayrıldım ve buldum.

Her neyse, çoğu zaman sorun olabilecek sadece senin projelerin değil. Çalışmalarım için onay aldığım ve saygı duyduğum bir işyerinde kendimi daha rahat buluyorum. İçinde bulunduğunuz durumla ilgili sorun, işvereninizin yalnızca oluşturulan projelerden kaynaklanan hataları fark edebilmesidir, diğer tüm böcekleri gidermek için harcadığınız zamanı değil.

Maaş

Daha fazla para istiyorsanız, sık sık elde edebilirsiniz. İki yılın altındaki maaşımı% 33'lük bir zam ile müzakere etmeyi başardım.

Temel olarak, işinizin değerini ve şirketin size ne kadar ihtiyacı olduğunu düşünün. Kazandığınız maaşı size veremezlerse, şirketin ya giderlerine bakması ya da işlerinin işe yaramadığını fark etmesi gerekir.

Ve burada birçok kişi tarafından bahsedildiği gibi ve katılıyorum, sen şirket yapbozunun çok değerli bir parçasısın. Kahretsin, muhtemelen bu bulmacayı çözebilecek tek kişi sensin. :)

Henüz yorum yapamadığım için, bu Stack Exchange sitesinde bir lurker olduğum için, buradaki bilgileri ekleyeceğim.

1. Yeni başladığınız için, Microsoft, Amazon ya da benzer bir şey gibi büyük bir şirkette çalışmaya gitmediyseniz, maaşınız yıldız olmayacak. Ama bu bir bakkal çalışanının işi olmamalı! Buna uzun süre dayanmayın, yaptığınız şeyi yaparak deneyim kazanın ve daha iyi bir fırsat ortaya çıktığında devam edin.

2. Giriş seviyesi bir konser için bu normaldir. İş yükünüz çok yüksek, ancak iş türü bekleniyor. Daha iyi bir geliştirici olmak için başkalarının hatalarından ders almalısınız. Ne kadar çok görürsen, o kadar iyi olursun. Ancak bu, öğrenilecek şeyler aradığınızı, kötü alışkanlıklar öğrenemediğinizi gösterir.

3. Bakımın proje çalışmasına oranı zaman içinde değişmelidir. Olmazsa, bu, çalıştığınız şirketin iyi bir geliştiriciyi nasıl koruyacağının farkına varmadığı anlamına gelir; aynı şeyi gün içinde ve gün boyunca yapmanı istiyorlar. Nerede olmak istediğinizi, maaşınızı ve iş beklentilerinizi akıllıca belirlemek ve buna göre hareket etmek için yıllık bir hedef oluşturun.

4) Mutlu değilseniz, bırakın! Hayat aptal insanlarla başa çıkmak için çok kısa.

Herşey gönlünce olsun.

Yapılacaklar listenizi takip etmek için bir sorun izleyici kullanmaya başlarsınız.

Bu sadece neyin kritik olduğunu takip etmenize yardımcı olmakla kalmayacak, aynı zamanda mevcut iş yükünüzün ne olduğunu görmede kullanıcılara ve patronunuza yardımcı olacaktır.

Ayrıca, ikinci bir geliştiriciyi hiç işe almazlarsa (veya istifa ederseniz ve yerine koymanız şimdi iş yükünüzü alır), bu iş yükünü yönetmenize yardımcı olur ve diğerlerinin ayak parmaklarına basmaktan kaçınabileceksiniz.

Bu zinciri kırmanın tek yolu esneklik için tasarlanmış ve tam ünite + entegrasyon testlerinden geçirilmiş yeni altyapılar geliştirmektir.

Bunu yönetime satmayı başarırsanız (diğer geliştiricileri ve yöneticileri konsepte 1: 1 toplantılarda imzalayın), o zaman, uygulama kodlarının çoğunun altyapı içinde olduğu ve durumun kolay olduğu bir duruma yavaşça erişebilirsiniz. genişletmek ve sürdürmek, gerçek uygulamaları hafif ağırlıklı ve oldukça hızlı bir şekilde yazılabilir.

Altyapının geliştirilmesi, önce mevcut uygulamaların parçalarının değiştirilmesini ve bir süre sonra (birkaç yıl sürebilir) tüm uygulamaların değiştirilmesini sağlayabilir.

Uzun vadede yeni uygulamaların geliştirme süresini ve gelecekteki mevcut uygulamaların bakım süresini büyük ölçüde azaltabilir.

Yeni gelişme, birden fazla geliştiriciden oluşan bir ekiple (birkaç zihin bir kişiden daha iyidir) en az% 80 özveri gerektirecektir (tercihen daha fazla). Tüm geliştiricilerin yaratıcı düşünebilmeleri ve mevcut önyargıları kırmaları gerekir.

Yeni bir altyapı tanımlamayı ve üst seviyeyi tasarlamayı deneyiniz, ardından tanımınızı emsallerinize ve yönetime sununuz.

Çalışma koşullarınızdan itibaren, bu konularla ilgilenen (tanımlarınıza ve tasarıma dayalı) yeni bir altyapı ekibine liderlik etmeyi isteyin ve gerektiğinde onlara yardımcı olurken eski şeyleri sürdürmeleri için yeni geliştiriciler getirin (% 10-20'ye kadar) zaman). Yönetim fikri kabul ederse şartlarınızı yeniden pazarlık etmeyi isteyebilirsiniz. Reddederlerse başka bir iş bulmaya hazır olun. (Unutmayın, işiniz beceri, bilgi ve tecrübe gerektirir, yerine inanmanız için para verdikleri kadar kolay değilsiniz.)

Yöneticiniz tüm bu değişiklik taleplerinin (bakım talepleri) farkında mı? Yaptırma yetkinizin bulunmadığı talepler doğrultusunda zamanınızın dolduğunu biliyor mu? Yoksa bir yönetici size her sorduğunda değişiklik mi yapıyorsunuz?

Bana öyle geliyor ki ilk görüşme noktanız hepsini yöneticinizin masasına koymak. Kimse size doğrudan gelmemelidir. Sorunlar bu tür alanları kimden bulmalı - genellikle bir destek ekibi. Kodunuzu kısa bir devir süresi boyunca desteklemeniz normaldir - genellikle bir hafta kadar. "Orta büyüklük" olarak sınıflanan herhangi bir şirkette değişiklikler maliyetlendirilmeli ve ücretlendirilmelidir (transfer ücreti) ve bu atlanacak gibi görünmektedir (sizi şaşkına çevirmelerine şaşmamalı - balodaki sürtük gibisiniz).

Hem sorunları arttırmak hem de talepleri değiştirmek için uygun bir talep prosedürü olmalıdır. Destek / bakım, hataların ve sorunların giderilmesiyle ilgilidir (orijinal teknik özelliklere uyan, ancak koddaki bir hata ya da dış olaydaki bir hata nedeniyle başarısızlık - kapatma veya bozuk yukarı akış sistemi vb.).

Şirketiniz bunlardan hiçbirini sunmuyorsa ve bu sayısız rastgele talebin üstesinden gelmenizi ve bunlardan sorumlu olmanızı bekliyorsa, cidden devam etmeyi düşünmeniz gerekir. Ödeme her zaman en düşük seviyededir - ilk programlama işimde (neredeyse 25 yıl önce) aynı şirket için 8 yıl geçirdim ve ücretim çok az arttı (her zaman bir kasiyerden çok daha yüksek olmasına rağmen). Ayrıldığım 2 yıl içinde iki katına çıkmıştım - ve bundan iki yıl sonra başladığımdan on kat daha fazla eve götürüyordum (fakat sonradan bağımsız bir müteahhitti). Her zamanki gibi, mahmuzlar kazan, ticaretini öğren ve daha sıcak bir çevreye gemi atla.

Belki de bir menajere gidip şunu söyleyeceksin: "Bak, seninle dürüst olacağım. Maaşım çok kötü, bu kez X’de giriş seviyesi programcısı olarak N kere alabilirim.

A, B ve C ile çok fazla şey yapıyorum. Bunu koruyamıyorum. Dürüst olmak gerekirse, hiçbir suç amaçlanmadı, bu odadan ya sabit olarak ya da istifa mektubum sizinle birlikte bırakılmış olarak yürüyeceğim. Şimdi bunların hepsi havada kaldı, bunu düzeltmek için nasıl birlikte çalışabiliriz? "

Cevap, anlaşılabilecek şekilde denemek ve açıklamaktır;

• Yağ değişimi gibi. Acil değiller ... ama düzenli olarak yapılmalı, hiçbiri az
• pas üzerinde boya ve harika görünecek. Kan akana kadar
• sağlamlaştırma destekleri olmadan yeni bir çatı veranda çatı masası oluşturmak. Belki bir süre çalışacak. Sonra çökecek ve insanları incitecek ve siz sorumlu olacaksınız.
• a / c harika. Bir pencere ünitesi bir veya iki oda için mükemmeldir. 146 pencere ünitesini klimaları bir binaya yerleştirmeye çalışıyorsanız sorun yaşarsınız.
• 5 çocuğa ders vermek iyi. 10'u fena değil. Ancak bazı sınırlar var. Gayri resmi 75 çocuğa öğretmeyi deneyin ve bunu göreceksiniz.

Bunlar rezonans değilse. Bırakın - Ertesi gün değil, YAZMA SUNULAN GÜN! Yeni bir işe sahip olduğunuzda, SIFIR bildiriminde bulunun. Kelimenin tam anlamıyla sadece o gün gelmiyor. Ama ne yaptığını bilen bir ya da iki meslektaşı olduğundan emin ol. Bu, aslında şirkete yardımcı olabilirse, saygısızlık ve kibirlerinin bir bedeli olduğunu göstererek şirkete yardımcı olacaktır. Son şirket DÖRT TEKNOLARIN ÜÇÜNÜNE GİTMEMESİ GEREKEN 6 AY ​​İÇİNDE KALDIR. En azından bir açıklama yaptı ve ayrılan kişiye bir keresinde söylemesi için iyi bir şans verdi: 'evet, her gün söylediğiniz kadar güzel ama bununla dolusunuz, size bildirimlerimin memnuniyetini bile vermiyorum.

Son olarak, bu ilişkilerin NORM olduğunu ve 20 yıl önce çevik, tdd, bdd ve yeniden düzenlemenin norm haline gelmesinden önceki standart olduğunu bilin. Hemen yanıtlayan kıdemli insanlarla konuşuyor olabilirsiniz: "bunu kendim yaptım ve iyi çalıştı, filan, filan, filan". Güzel atlar ve at arabaları 150 yıl önce iyi çalıştı. Teknoloji alanlarında, 20 yıl öncesinden teknikler, 150 yıl öncesinden kalma ulaşım kadar eskidir. Bu cezayı reddederlerse. Sadece, etrafta kalacak olan iyi ve güncel teknoloji geliştiricilerini asla işe almayacaklarını bilin. En kötüsünün en kötüsünü alırlar ve işlerini korkunç derecede incitirler. Eğer teknolojiye bağlılarsa ve adapte olamazlarsa başarısız olurlar ve sonuçta bu sizin için en iyi ödül olabilir. O'

Yönetiminiz temel olarak size saygı duymuyor veya iş yükünüzü anlamıyor gibi geliyor.

Gelen her özellik isteğini yerine getirmemelisiniz. Yöneticiniz siz ve gelen istekleriniz arasında bir arabellek görevi görmelidir (belki de en basit kesme / düzeltme istekleri hariç). O zaman sizinle birlikte oturmalı ve onaylanan taleplerin uygulanabilirliğini ve önceliğini belirlemelidir.

Ayrıca, muhtemelen ödedikleri parayı en az 2 kat yapıyor olmalısınız.

Muhtemelen sizinle birlikte çalışmak için en az 1 geliştiriciye ihtiyaç duyuyorlar gibi geliyor, ama size ödedikleri şey oldukça olası gibi görünüyor.

Size yeterince ödeme yapmak istemiyorlarsa ya da iş yükünüzü yönetmenize yardımcı oluyorlarsa, yeni bir iş arıyorum. Bir ekibin parçası olduğunuz ve projelerinizi tamamlamak için yönetiminizin sizinle birlikte çalıştığı bir yerde çalışmak istersiniz. Batan gemiden olabildiğince çabuk çık.

Bir takımda bir kahraman olmak sadece seni yakacak.

Ben sadece bir öğrenciyim (hala) ama bu oldukça normal (staj deneyimimden). Destek ve web uygulamalarında çalışırken elde ettiğiniz budur.

Kodlamaya başlamadan önce müşterinin (yöneticinin) ne istediğini anlamanızı tavsiye ederim. Bu zor olabilir, çünkü bazen kendileri bilmiyorlar, bu yüzden bir konuda hemfikir olana kadar onlarla birlikte çalışın. Kodlamadan önce her ikisinin de son çözüme karar verdiğinden emin olun.

Ayrıca, bir koruyucuysanız, koddaki herhangi bir şeyi hemen hemen değiştirebilirsiniz - yalnızca davranışını değiştirmediğinden veya hatalara neden olmadığından emin olun. Yöneticilerin hiçbir şeyi değiştirmenize 'izin vermemesini bekliyorum, çünkü artık alıştıkları ve mutlu oldukları ve yeni değişiklikler için para ödemek istemedikleri için mutlular.

Sonunda, başka bir şey yaptığınız için bir şeyle başa çıkamazsanız endişelenmeyin. İnsanlara işle boğulmuş olduğunuzu ve onların isteklerinin zaman alacağını bildirmenizi öneririm. Yöneticileri yoksa sadece tembel olduğunu düşünürdüm. Zaten işiniz olduğunu ve daha fazla insanı işe alabileceklerini bilmelerini sağlayın. Çalışmanın tek bir kişi için çok fazla olduğunu bilmelerinin başka yolu yoktur.

Bu bir proje yönetimi problemidir. Neyin üzerinde çalışılacağına karar vermek için bir tür proje yönetimi kullanın.

a) Üzerinde çalışmak için bir parça birikimine ihtiyacınız var. Biriktirme listesindeki kodu geliştirme planınızı koyarsınız.

b) Tüm böcekler birikintiye girer

c) Biriktirme listesi öncelik kazanır.

d) Hepsini öncelik sırasına göre yaparsınız.

Hatalar çok daha yüksek bir öncelik olabilir, ancak bir kez yeni özelliklere veya yeniden yapılanma tasarımına harcayacağınız döngüleri düzeltirseniz.

Düzeltmeleri gereken sorunların / hataların bulunduğu bölümlerin üzerinden geçtiğinizde, yalnızca aşamalı olarak iyileştirmelerde yeniden yapılanma yaparsanız en kolay yoldur. Daha sonra yönetime, “A'yı düzeltmem gerekiyordu, ancak B temelde kırılmıştı ve hepsini düzeltmek için C çözümünü yapmak zorunda kaldım, böylece D'nin gelecekte daha kolay / daha ucuz olmasını sağladım” Where A = Böcek, B = The anti-patern, C = Çözüm, D = Gelecek Kazançları

İşi yapmaya değer bir yatırım olarak haklı çıkaramazsanız, iş adamları asla kabul etmez.

Bu her zamanki gibi bir iştir. Orada çalışmaya devam ettiğiniz sürece sömürüleceksiniz. Yaptığınız işte kendinizi mutlu hissetmek yerine, bu modele devam etmek firmanın çıkarınadır. Aşağı geldiğinde, gerçekten umursamıyorlar. Bu onlar için güvenilir bir kod oluşturmakla ilgilidir ve tek kişilik bir grupsanız, kesinlikle bankanız olurlar. Neden değişsinler?

Tüm bunlardaki iyi haber, bilmeseniz bile onlar için bir VIP olmanızdır. Yapmamı önerdiğim, gemiye atlamadan önce daha fazla fırsatı sıraya koymak, sonra topları ellerinden almak ve daha yüksek bir maaş talep etmek. Daha iyi bir fırsata taşınmazsanız. Benim düşünceme göre, yakında biraz daha heyecan verici bir iş bulmalısın. Yapabildiğin kadar yükseğe nişan al. Bir geliştirici dükkanına ulaştıktan sonra, Google ya da gerçekten mutlu hissedeceğiniz işbirlikçi bir geliştirici kültürünün olduğu eğlenceli bir başlangıç ​​gibi daha mutlu olacaksınız.

Şahsen yaptığım, bir baş avcısı müteahhitlik organizasyonunu kullanmaktı ve hızlı bir şekilde, benim müteahhitimden sürekli bir iş tutarken birinden diğerine geçerek, kemerimin altında çok büyük deneyimler yaşadım. Sizi sıkılmaktan alıkoyuyor ve sizi zorluyor. Sonunda, boş zamanlarımda asıl işe dönüşen küçük bir işletme kurdum ve daha sonra kontrat işi yapmaktan gemiye atladım.