Nasıl Daha İyi Bir Yazılım Geliştiricisi Olunur?

 Nasıl Daha İyi Bir Yazılım Geliştiricisi Olunur?
Okunuyor Nasıl Daha İyi Bir Yazılım Geliştiricisi Olunur?

Bugün, bir yazılım geliştiricinin mesleki becerilerini geliştirebilecekleri ve işlerinde daha iyi hale gelebilecekleri yollarla ilgili bazı düşüncelerimi paylaşmak istiyorum. Burada gündeme getirilen konular evrenseldir ve herhangi bir teknoloji yığınına özgü değildir. Bu nedenle, çoğu BT’ye özgü bile değil. Bunlar, kişisel özelliklerinizi nasıl geliştireceğiniz, meslektaşlarınız ve müşterilerinizle işbirliğini nasıl iyileştireceğiniz ve bir yazılım geliştiricisi olarak kariyerinizi nasıl ilerleteceğiniz konusunda genel tavsiyelerdir.

Bu makaledeki şeylerden bazıları özneldir ve benim kişisel deneyimimi yansıtırken, diğerleri başkaları tarafından benimsenmiş ve başarıyla kullanılmıştır.

İçindekiler

Süreci Uçtan Uca Anlayın

Pek çok geliştirici, yazılım geliştirmenin tamamen kodlamayla ilgili olduğunu düşünüyor ve geri kalan her şey sadece insanların can sıkıcı olmaya ve değerli zamanlarını boşa harcamaya çalışmaktan ibaret. Bu gerçeklerden daha uzak olamaz. Bir yazılım parçasını kodlamadan önce, belirsiz bir fikirden uygulamaya hazır, dikkatlice tasarlanmış bir çözüme dönüşüm sürecinden geçer. En son değişikliklerinizi Git’e aktardıktan sonra, yazılım test ediliyor, dağıtılıyor, izleniyor, analiz ediliyor ve geliştiriliyor. Kodlama, sürecin birçok adımından sadece biridir.

Peki bu neden oluyor? Sıklıkla, özellikle daha büyük organizasyonlarda çalışırken, projelerin farklı aşamaları farklı ekipler hatta departmanlar tarafından ele alınır. Her şey, gereksinimleri toplayan iş analistleriyle başlar. Gereksinimler daha sonra geliştiriciler için mockupları üreten tasarımcılara teslim edilir. Geliştiriciler kodlar ve sonuçları QA mühendislerine verir. Her şey yolundaysa yapı, onu son kullanıcılara teslim eden operasyon ekiplerine gönderilir. Bu süreç, herhangi bir geri bildirim olmaksızın bir dizi ayrı adım olarak değerlendirilir. Departmanlar arasındaki iletişim eksikliğinden dolayı temsilcileri genellikle başkalarının hedeflerini gerçekten anlamaz ve bu yanlış anlamalara ve hatta çatışmalara yol açar.

Genellikle yazılım geliştirme süreci, geri bildirim içermeyen bir dizi ayrı adım olarak ele alınır.

Günümüzde birçok insan için bu çok abartılı gelebilir. Çevik metodolojilerin yükselişiyle, daha fazla şirket bu kadar katı bir yaklaşımdan karma uzmanlık alanlarından oluşan daha küçük ekiplere doğru kayıyor. Ama o zaman bile insanların başkalarının çalışmalarını gerçekten anlamaya çalışmadıklarını görüyoruz. Tasarımcılarınız, çok zaman alan özel bir onay kutusu uygulamanızı istedikleri için ne sıklıkla rahatsız oldunuz? Ve tam tersi, eleştiri aldı, çünkü doğru yazı tipini kullanmayı unuttun.

Bu farklılıkların çoğu, sadece başkalarının çalışmalarına dikkat edilerek aşılabilir. Tasarımcınızla oturun ve ona özel bir onay kutusu uygulamanın biraz zaman aldığını ve yeniden kullanabileceğiniz farklı bir benzer onay kutusu sunan bir kitaplık olduğunu açıklayın. Buna karşılık, tipografinin temellerini öğrenin ve doğru yazı tipi seçmenin neden bir fark yarattığını anlayın. Yöneticilere, iş analistlerine, kalite kontrol mühendislerine, destek ve pazarlama uzmanlarına karşı aynı tutumları geliştirin. T. Huxley’den alıntı:

Her şey ve bir şeyler hakkında her şey hakkında bir şeyler öğrenmeye çalışın.

Herkesten bir şeyler öğrenerek, ihtiyaçlarını önceden tahmin edebilir, geri bildirim döngüsünü kısaltabilir ve daha sık teslimatlara olanak sağlayabilirsiniz. Ayrıca, size herkesten çok fazla sevgi ve saygı kazandıracak.

Müşterinizin İhtiyaçlarını Anlayın

Müşterileriniz hakkında anlamanız gereken önemli bir şey var: Yaptığınız şeylerin çoğunu anlamıyorlar. Çevik, işlevsel programlama veya ilişkisel olmayan veritabanları onlar için karanlık bir sihirbazlıktır. İşinizi yakından takip eden ve gerçekten ilgilenenler bile hala çoğunlukla karanlıktadır. Bunun birkaç sonucu var.

Yazılım geliştiricilerle konuşurken çoğu müşterinin yüzü.

Yazılım geliştiricilerini onlar için işe almak belirli bir ölçüde güven gerektirir. İnsanlar genellikle anlamadıkları bir şey için çok para ödemek zorunda kalmaktan rahatsız olurlar. En son bilmediğiniz bir araba tamir servisine girdiğinizi ve yolculuğunuzda onlara güvenip güvenemeyeceğinizden emin olamadığınızı hatırlıyor musunuz? Müşterileriniz de aynı duyguya sahip. Araba olmaması dışında, bir şekilde ürünlere ve gelire dönüşmesi beklenen bir sürü soyut somut olmayan kavram var. Yeni müşterilerle çalışırken onların güvenini kazanmak önemlidir. Nasıl çalıştığınızı anladıklarından ve sonuçları daha küçük ama sık yinelemelerle sunmayı hedeflediklerinden emin olun. Bu şekilde çalışmanızın ilerlemesini görebilir, ara sonuçları değerlendirebilir ve geri bildirimde bulunabilirler.

Genellikle müşteriler sorunlarını paylaşmak yerine kendi çözümlerini bulma eğilimindedir. Yetenekleriniz hakkında çok az fikirleri olduğu için, çözümleri genellikle yanlış değerlendirilir, yetersiz veya aşırı hırslıdır. Henry Ford’un eski (ve belki de kurgusal) sözünü hatırlayın:

İnsanlara ne istediklerini sorsaydım, daha hızlı atlar derlerdi.

Akışa devam etmek ve müşterinin istediği şeyi sessizce uygulamak yerine, bazen onları bir adım geri çekmeye ve ilk başta çözmek istedikleri sorunu tartışmaya davet etmek yararlıdır. Alan bilgilerini ve teknik uzmanlığınızı birleştirirken, muhtemelen daha iyi bir çözüme ulaşacaksınız.

Unutmayın, herkesin fikirlerinin sorgulanmasından hoşlanmadığını ve bu taktiğin biraz incelikli olmanızı ve müşterinin gözünde güven uyandırmanızı gerektirdiğini unutmayın. Sorunu anlayabilmek ve daha iyi bir çözüm önerebilmek için konfor alanınızdan ayrılmanız ve kendinizi onların işine dahil etmeniz gerekecektir. Finans veya sağlık hizmetleri gibi karmaşık sektörlerde çalışıyorsanız, bu zor olabilir. Ancak bunu bir kez yaparsanız, müşteri bir dahaki sefere daha açık bir fikirle geri dönecektir.

İş için Doğru Araçları Seçin

Sahip olduğunuz tek şey bir çekiçse, her şey bir çivi gibi görünür.

Genellikle tek bir teknolojiyi öğrenen geliştiriciler, karşılaştıkları her soruna bunu uygulamak için acele ederler. Şaşırtıcı olmayan bir şekilde, bu tür bir yaklaşım, optimalin altında sonuçlara yol açar. Bunun yerine, yeni bir problemle uğraşırken durun ve emrinizdeki aletlerin bu tür işler için gerçekten uygun olup olmadığını düşünün. Şüpheleriniz varsa, biraz araştırın ve olası üstün alternatiflerin bir listesini bulun. Kolaylaştırmak için bir soru listesi oluşturun ve farklı seçenekleri tek tek değerlendirin. Sorular her değerlendirme için farklı olabilir, ancak şu şekilde olabilir:

  • Hangi platformları veya cihazları desteklemesi gerekir?
  • Performans veya bellek kullanımı gibi işlevsel olmayan gereksinimler nelerdir?
  • Lisans satın almak bir seçenek mi yoksa ücretsiz veya açık kaynaklı bir şeye mi ihtiyacınız var?
  • Çözüm, ihtiyacınız olan her şeyi kutudan çıkarıyor mu yoksa kendiniz bir şeyler mi yazmanız gerekiyor?
  • Şirket politikaları, yasal hususlar veya ekibinizde uzman eksikliği gibi başka sınırlamalarınız var mı?

Bu soruları cevaplamak, kafanızdaki seçenekleri yapılandırmanıza ve bunları kısa bir aday listesine indirmenize yardımcı olmalıdır.

Güvenle Deney Yapın

Öyleyse, bildiğiniz hiçbir şey sizin durumunuza uygun değilse ve yeni bir şey denemek istiyorsanız ne olur? Bir şeyi deneyimlememeniz, otomatik olarak bunun söz konusu olmadığı anlamına gelmez. Bu sadece bazı ek şeyleri düşünmeniz gerektiği anlamına gelir:

  • Hazırlık için yeterli zamanınız var mı? Projenin zaman çizelgesi stresli değilse, uygulamaya başlamadan önce mümkün olduğunca çok şey öğrenebilir ve geri kalanını yol boyunca alabilirsiniz. Ya da en azından ” yapana kadar taklit et ” yaklaşımını benimseyin ve müşteriyi ne yaptığınızı bildiğinize ikna edin.
  • Önce test etmeniz gereken şeyleri belirleyin. ” Hızlı başarısız ” yaklaşımını kullanın ve deneyi sonuçlandırmadan önce değerlendirmeniz gereken önemli şeyleri belirleyin. Bir sistemin performansı hakkında şüpheleriniz mi var? Minimal bir prototip oluşturun ve bir yük testi çalıştırın. Belirli bir kitaplık veya harici bir hizmetle entegrasyon hakkında emin değil misiniz? Bunu ayrı ayrı uygulayın ve ardından gerisini oluşturun.

Bu yolda ilerlemenin hem siz hem de müşteriniz için hala riskli olduğunu ve hem risklerin hem de potansiyel faydaların farkında olmaları gerektiğini unutmayın. Ne de olsa, uzun vadede aylarca çalışmayı kurtarabilecek iki haftalık bir araştırma, bu oldukça iyi bir anlaşma gibi görünüyor. Deney başarısız olsa bile, yalnızca iki hafta kaybedersiniz. Müşterinize ne kadar güvenirseniz, bunun gibi bir şeyi o kadar çok kabul edeceklerdir.

Devlerin Omuzları Üzerine İnşa Edin

Bisikleti yeniden icat etmek genellikle tuhaf sonuçlara yol açar.

BT çalışanlarının genellikle iki ortak özelliği vardır: Biz yaratıcıyız ve işimizden zevk alıyoruz. Bu iyi bir şeye benziyor, ancak tuhaf bir yan etkiyle geliyor: daha önce çözülmüş sorunlara kendi çözümlerimizi bulma eğilimindeyiz. Bu nedenle, bir çerçeve, kitaplık veya hizmet kullanma veya kendi başımıza uygulama seçimiyle karşı karşıya olduğumuzda, ikincisini seçme eğilimindeyiz. Bu da bizi tekerleği yeniden icat etmenin beyhude yolculuğuna çıkarıyor. Buna yol açan yaygın yanlış inançlardan bazıları şunlardır:

  • Bir şeyi kendiniz uygulamak, üçüncü taraf bir çözümü öğrenmekten daha kolaydır. Bu tamamen geçerli bir neden olsa da, eldeki görevi fazla basitleştirmemek önemlidir. Genellikle, bir şeyler başlangıçta basit görünür, ancak ilerledikçe çok daha zor hale gelir. Sonunda, birisinin sizin için halledebileceği hataları ve uç durumları ele almak için bir sürü zaman harcayabilirsiniz.
  • Bu çözüm ihtiyacım olandan daha fazlasını yapıyor. Ortaya çıkan yapının boyutunu artırmak, olası güvenlik açıkları eklemek veya yapıyı önemli ölçüde yavaşlatmak gibi bunun kötü bir şey olmasının belirli nedenleri olmadıkça, bu genellikle kötü bir şey değildir. Daha sonra ihtiyacınız olabilir. Öte yandan, tek bir işlevi kullanmak için bütün bir kitaplık eklemek aşırı olabilir.
  • Daha iyisini yapabiliriz. Bu sözlerle başlayan bazı başarılı projeler olsa da, genellikle durum böyle değildir. Kaliteli üçüncü bölüm çözümleri, bu sorunu çözmeye adanmış deneyime ve kaynaklara sahip ekipler tarafından sürdürülür. Onlarla rekabet edebilmek için daha fazla yatırım yapabilmelisiniz. Çoğu projenin bunu yapmak için ne kaynağı ne de ihtiyacı vardır.
  • Kod sahipliği ve uzun vadeli bakım bir sorun haline gelecektir. Bazı insanlar, üçüncü taraf bir çözümle giderseniz, projenin bir noktada terkedilebileceğini veya herhangi bir nedenle kullanılamaz hale gelebileceğinden korkuyor. Ürüne kilitlenme riski gerçektir ve olası bir azaltma stratejisi düşünmelisiniz. Açık kaynaklı bir proje ise, kendi başınıza kurmanız ve sürdürmeniz mümkün olur mu? Ya da özel bir proje ise, onu değiştirmenin maliyeti nedir? Bu girdilere dayanarak, riske değip değmeyeceğine dair bilinçli bir karar verebilirsiniz.

Yeniden Uygulama Yoluyla Öğrenin

Bu hikayenin başka bir yanı var. Bir şeyi kendi başınıza yeniden uygulamak aslında öğrenmenin harika bir yoludur. Bir üretim projesi için kendi çerçevenizi yazmak neredeyse her zaman kötü bir fikir olsa da, onu bir öğrenme alıştırması olarak oluşturmak çok değerli olabilir. Kendinizi aynı sorunlara çözüm getirerek çözdüğü sorunlara alıştırmanın daha iyi bir yolu. Tavşan deliğine çok fazla girmeyin, basitleştirilmiş bir kaba uygulama size durumu anlamanız için yeterli olacaktır.

Siz oradayken, benzer projelerin kaynaklarına göz atmaktan çekinmeyin. Açık kaynaklı projelerin kodlarını incelemek, daha deneyimli geliştiricilerin deneyimlerinden yararlanmanızı sağlayacaktır.

Nasıl Çalıştığınız Üzerine Çalışın

Yalnızca teknolojik açıdan değil, aynı zamanda metodolojik açıdan da iyileştirmeler için çaba gösterin. Düzgün tasarlanmış ve optimize edilmiş yazılımlar gibi, iyi kurulmuş bir iş akışı, daha iyi sonuçlar üretirken daha az çaba ve stresle çalışmanıza olanak tanır. Etkili ve verimli bir çalışma süreci oluşturmak kolay bir iş değildir ve bu konuda çok sayıda kitap ve materyal mevcuttur. Ancak başlangıç ​​olarak, aşağıdaki iyileştirme alanlarını göz önünde bulundurun:

  • Takım ve proje yönetimi metodolojileri. Çoğumuz ekipler halinde çalıştığımız için, işbirliğini geliştiren ve herkes için ortak bir çalışma ritmi oluşturan bir süreci benimsemek önemlidir. Yazılım geliştirmedeki çevik hareket, Scrum veya Kanban gibi yaygın olarak benimsenen bir dizi metodolojiyi doğurmuştur . Genel çalışma yapısını düzenlemeye yardımcı olurlar ancak her şeyi kapsamazlar. Tahminler yapmanıza, sorunları önceliklendirmenize, iletişimi geliştirmenize vb. Yardımcı olan başka metodolojiler de vardır. Mücadele ettiğiniz alanları belirlemeniz ve mücadelelerinize çözüm getirecek en iyi uygulamaları aramanız gerekecektir.
  • Kişisel süreçler. Bir orkestra gibi, etkili bir takımın aynı ritme sahip olması gerekir, ancak bu herkesin aynı şekilde çalışması gerektiği anlamına gelmez. Her kişinin kendi tercihleri ​​vardır ve onları daha üretken kılacak şekilde çalışmalıdır. Örneğin, pek çok insan kod yazarken saatlerce rahatsız edilmekten hoşlanmaz, ama ben şahsen, aralarında molalar olan bir-iki saatlik kısa aralıklarla çalışmayı seviyorum ( pomodoro tekniğinin daha az katı bir versiyonu ). Ayrıca evle ilgili dikkat dağınıklığından kaçınmak için evde çalışmayı sevmiyorum ve bir ofis veya kafede çalışmayı tercih ediyorum. Sizin için neyin işe yaradığını bulun ve ona bağlı kalın, ancak alışkanlıklarınızın diğer ekip üyeleri için sorun yaratmadığından emin olun.
  • Mühendislik uygulamaları . Pek çok uygulama, teknoloji ve metodoloji arasındaki sınırda yer alır ve gerçek geliştirme sürecini iyileştirmeye odaklanır. Örneğin, test odaklı geliştirme ve davranış odaklı geliştirme , kod tabanınızın iyi yapılandırılmış ve test edilmiş olmasına yardımcı olur. Kod incelemeleri , koddaki kusurların azaltılmasına ve ayrıca ekibe bilginin yayılmasına yardımcı olur. Sürekli entegrasyon ve sürekli teslimat , daha kolay ve daha güvenli bir dağıtım süreci sağlar. Maksimum sonuçları elde etmek için bu uygulamaları diğer organizasyonel metodolojilerle birlikte kullanın.

Unutmayın, herkes için işe yarayacak bir süreç yoktur, kendi ortamınızda denemeniz gerekir. Ayrıca, süreci tamamen anladığınızdan ve doğru uyguladığınızdan emin olun. Süreci daha önce tamamlamış ve deneyimlerinden faydalanan ekiplerden tavsiye alın. Bir süreci benimsemenize yardımcı olacak yazılım ve malzeme araçlarını ihmal etmeyin. Gerçek bir Kanban panosu ve kesintisiz teslimat için modern bir platform edinin. Yeni bir sürecin benimsenmesi çaba gerektirecek ve hatta kısa vadeli bir üretkenlik kaybına yol açabilir. Biraz zaman tanıyın ve ardından işlerin iyileşip iyileşmediğine dair bir değerlendirme yapın.

Engelleri Kaldır

Engelleri ele almak için ayrı bir şey söylenmelidir. Önemli görünmeyen ancak aslında işiniz üzerinde toksik etkisi olabilecek küçük rahatsızlıkları ihmal etmek yaygın bir hatadır. Ürün tasarımcınız ayrı bir odada veya binada mı oturuyor? Bu, gelip sohbet etmenin biraz daha çaba gerektirdiği ve bazı şeylerin tartışılmayacağı anlamına gelir. Yeni bir test yazmak zor mu? O zaman pek çok şey test edilmeyecek.

Bunların hiçbiri tek başına tehlikeli değildir, ancak yığılma ve ciddi sonuçlara neden olma eğilimindedirler. Ve çirkin olan şey, çok geç olana kadar çoğu zaman onları fark etmemenizdir. Özellikle her zaman ele alınması gereken daha ciddi tehlikeler olduğunda. Kaynayan kurbağa hakkındaki masal ve sürünen normallik fikrini hatırlayın .

Tetikte olun ve bu şeylerle size ulaşmadan önce köklerinde savaşın.

Temellere Odaklanın

http://www.webodasi.com

BT son derece hızlı ilerleyen bir endüstridir. Her hafta yeni araçlar piyasaya sürülür. Önceki yazımda kötü şöhretli ” JavaScript yorgunluk ” sendromundan daha önce bahsetmiştim . Birçok geliştirici strese girdi ve her yeni projede JS teknoloji yığınlarını yeniden değerlendirmek zorunda kaldı ve bu da onları çılgına çevirdi. Aslında, her zaman sınırda olmak zor olabilir, ancak bunu kolaylaştırabilecek birkaç fikir var.

Her şeyden önce temellere odaklanın. Yeni teknolojiler oldukça sık ortaya çıksa da, yeni temel kavramlar çok daha nadirdir. Yeni bir şey öğrenirken, bu uygulamaya yol açan temel fikirleri anladığınızdan emin olun. Muhtemelen, bu fikirler başka projelerde de kullanılıyor ve benzer bir şeyle karşılaştığınızda, onu kavramanız daha kolay olacaktır. Örneğin, modern JavaScript UI çerçeveleri bileşenlere dayalıdır ve React kullanarak bileşen odaklı bir uygulamanın nasıl yapılandırılacağını anladığınızda, bu deneyimi Angular ile çalışırken kullanabilirsiniz. Benzer bir şekilde Redux fikirleri de Angular’a girdi ve Angular’dan reaktif durum yönetimi MobX olarak React için uygulandı.

Gregor Hohpe ve Bobby Woolf’un yazdığı ” Enterprise Integration Patterns “, Gang’ın ünlü ” Design Patterns: Elements of Reusable Object-Oriented Software ” gibi yazılım geliştirmedeki yaygın kalıplarla ilgili klasik kitaplara aşina olmak için biraz zaman ayırın Martin Fowler’ın dört veya farklı eserinden. Kitaplarda anlatılan bazı şeylerin modası geçmiş olsa da, bunları kalıpların bugüne kadar nasıl geliştiğini öğrenmek için kullanabilirsiniz.

İkinci olarak, oradaki her yeni şeyi öğrenmek için acele etmeyin. Hacker News’de görünen her yeni şeyi takip etmenin cazip olduğunu anlıyorum, ancak bunların çoğu sadece gürültü. Bunun yerine, toplulukta bir süredir etrafta dolaşan ve ilk tartışmaların ötesinde olgunlaşan şeylere dikkat edin. FOMO’ya teslim olmayın . En azından neler olup bittiğine biraz dikkat ederseniz, önemli hiçbir şey gözden kaçmayacaktır.

Bonus İpuçları

Bu makalede zaten çok şey konuştuk, ancak bitirmeden önce vurgulamak istediğim birkaç nokta daha var. Bu birkaç ipucu profesyonel olmaktan çok kişisel özelliklerinize odaklanıyor, ancak yine de iş hayatınız üzerinde yüksek bir etkiye sahip olduğuna inanıyorum.

Bilgiyi paylaşın

Çoğu zaman insanlar değerli bilgileri biriktirmenin onları vazgeçilmez kılacağını düşünür. Ekibinizde böyle insanların olması sizi “ otobüs faktörü ” ne maruz bırakır ve eğer böyle bir kişi projeden ayrılırsa sizi zor bir duruma sokabilir. Bu insanlardan biriyseniz, sizi vazgeçilmez kılmanın yanı sıra, uzmanlığınızın da sizi terfi edilemez ve “tatil edilemez” kıldığını düşünün. Organizasyonunuzdaki diğer kariyer fırsatlarını kaçırabilirsiniz çünkü bu role bağlısınız. Bunun yerine, bilgiyi meslektaşlarınızla paylaşın, eğer mümkünse işinizin bir kısmını onlara devredin ve bu işbirliğini işlerinin üzerine daha da büyük şeyler inşa etmek için kullanın.

Kendinizi veya başkalarını suçlamayın

Uzun zaman önce bir projede benim hatamla bir olay yaşadığımızı hatırlıyorum. Olaydan oldukça hızlı bir şekilde kurtulmayı başardık ve müşterinin bana şunu söylediğini hatırlıyorum:

Bir takımı, her şey plana göre gittiğinde nasıl performans gösterdiklerine göre değil, fana çarptığında nasıl çalıştıklarına göre yargılarsın.

Ne kadar iyi olursanız olun, bazen işler ters gidebilir ve böyle anlarda soğukkanlılığınızı koruyabilmeniz ve durumu haysiyet ve karşılıklı saygı ile idare edebilmeniz önemlidir. Yangın söndürüldükten sonra günah keçisini bulmaya odaklanmayın. Bu, gelecekte hatalardan kaçınmanıza yardımcı olmayacak, ancak şirket genelinde korku ve şüpheye yol açacaktır. Bunun yerine, etkilenen taraflarla bir araya gelin ve ortak bir otopsi yapın. Soruna neden olan şeylere odaklanın, bunun neden olduğunu anlayın ve gelecekte bu sorunu önlemek için sisteminizi veya iş akışınızı nelerin iyileştirebileceği üzerine beyin fırtınası yapın

Pislik olma

Geliştirici topluluğu komik bir şey. Bir tarafta, açık kaynaklı projeler üzerinde çalışarak, konferanslarda konuşmalar yaparak veya makaleler yazarak topluma katkıda bulunan pek çok açık fikirli insan görüyoruz. Öte yandan, yeni fikirleri trolleyen, yeni gelenlere saygısızlık eden ve etrafındaki herkese kaba davranışlar sergileyen insanlarla karşılaşıyoruz. O insanlardan biri olmayın. Nazik ol ve sevgiyi yay.

Pek çok profesyonel tavsiye sadece dört kelimeyle özetlenebilir.

Sarmalamak

İşimizle ilgili en iyi şey, bir sınırı olmamasıdır. Her zaman seyahat edilecek yeni yollar ve katledilecek ejderhalar vardır. İster yolculuğunuzun henüz başında olun, ister deneyimli bir profesyonel olun, bunları aklınızda bulundurun. Yolunuzu bulmanıza ve atılan her adımda daha iyi bir geliştirici olmanıza yardımcı olmalıdırlar.

Başkalarıyla paylaşmak için farklı tavsiyeleriniz var mı? Yorumlarda yayınlamaktan ve bir tartışma başlatmaktan çekinmeyin!

Dilerseniz Bir Sonra Ki Blog Sayfalarımıza Göz Atabilirsiniz..

Görüşmek Üzere Hoşçakalın WebOdasıyla Kalın..

Yorum Yap