Bir süredir yaz(a)mıyorum, Ramazan ayı vesilesiyle hala hayatta olduğumu hatırlatayım dedim…

Bu yazıya da biraz anlam katmak için sizi Sorularla İslamiyet sitesinin Ramazan Sayfaları’na gönderiyorum.

21 Haziran’da İstanbul’da Genç Girişimciler Kulübü’nde IT Sektöründe Kişisel Gelişim ve Kariyer isimli bir konuşma yapacağım. Açıkçası bugüne kadar yaptığım güvenlikle alakalı olmayan ilk konuşma olacak.

Etkinlik ücretsiz, siteden kayıt olmanız yeterli.

25 Haziran’da Ankarada 5. Kamu Kurumları Bilgi Teknolojileri Güvenlik Konferansında konuşuyor olacağım, genelde demo ağırlıklı bir şekilde web uygulamalarındaki güvenlik açıklarından bahsedeceğim.

Konferansa katılım ücretsiz ama sitesinde belirtildiği şekilde kayıt olmanız gerekli.

Bir süredir yazamıyorum bu da yazamadığım vakitlere denk geldi. Hakin9 benimle bir röportaj yaptı, ek olarak Hakin9 artık ücretsiz olarak internet yayınlanmaya başladı, şuradan download edilip okunabilir.

Maalesef geliştiriciler olarak “kabul edilemez” listemiz gereğinden çok daha fazla ve esas gerçeği düzenli şekilde unutuyoruz. “Ürün çözmek için geldiği sorunu en iyi şekilde çözüyor mu? Size diğer tüm eksik ve hataları göz ardı etmenizi sağlayacak birşeyler sunabiliyor mu?”

Bakalım neler yapmadan da bir yazılım yapabiliyormuşuz ve başarılı olabiliyormuş, benden iki örnek:

• Google Chrome
• Otomatik update ekranı yok, (hakkında sayfasında çok basit bir göstergesi var)
• Proxy desteği yok (sadece SYSTEM proxy’ sini kullanıyor)
• Normalde ihtiyacınız olabileceği ama olmadan da yaşayabileceğiniz bir milyon özellik yok (Firefox / IE ayarları ile Chrome’ un ayarları arasında 10 kat kadar fark var)
  
• Hacker News
• Şifrenizi unutursanız hatırlatma desteği yok,
• Arama yok
• Kategori, tag vs. yok

Bu tip özellikler ileride gerekebilir ama v1.0 de gerçekten o özelliğe ihtiyacınız var mı? Şimdi kesinlikle olması gerekenler listenize tekrar bakın ve yarısını silip aslında abarttığınızı itiraf edin.

Unutmadan insanların bir özelliği istemesi o özellik olmayınca yazılımı kullanmayacağı anlamına gelmiyor.

Sizin bildiğiniz bu şekilde başarılı ama çok bariz özellikleri olmayan ürünler var mı?

I wrote this article about 2 years ago in Turkish. Recently Whitehat released a quite nice paper about vulnerability counts per programming language/framework. That report kind of backs up this article however many took and advertised it wrongly as it sounded like “choice of framework has virtually no effect on security”. So I decided to write it in English again.

One of the oldest clichés in web application security is:

"Choice of framework doesn't matter"

I say bullshit!

Good Developers Always Develop Secure Applications

Yes, one can write a secure web application using brainfuck in 1 year and after 250 iterations. She can start by "implementing her own session handling and make it secure". That sounds funny, right? But when I say "All you need to do is implement your own CSRF protection", it doesn't sound funny because that's what everyone is keep doing. However to me it's still wrong, just like a secure session implementation a secure CSRF protection implementation should be one of the responsibilities of the framework not the developer.

Security of the Language, Security of the Framework

There is no perfect framework, vulnerabilities identified in all frameworks just like vulnerabilities identified in all applications. However just like some applications security track of some frameworks are much better. ASP.NET Request Validation Bypass, PHP Zend_Hash_Del_Key_or_index overwrite issues, Struts Validation Bypass are good examples of these vulnerabilities.

PHP is a perfect example of this. PHP itself has so many vulnerabilities (such as Zend_Hash_Del_Key_Or_Index Vulnerability, month of PHP bugs and others) even when the developer codes everything securely it still can be vulnerable. I don't even mention the terrible design issues such as GLOBALS Overwrite problems, magic quotes, providing not one but several different functions to do the very same job.

If you set a directory as protected and if your framework can't protect you because the attacker used a different HTTP Method then that's not the developer's fault, it's framework's fault.

That's why framework matters, even when you build the most solid application when your framework is weak, there is a higher possibility of getting owned.

Can framework handle unicode characters correctly? Do functions unexpectedly effected by null bytes? Does it spill out all the details when you send one character in the cookie?

All of these are problems of the framework. If you are wise enough you should choose a framework with a good track of security.

Framework Specific Issues

You won't see much RFI (Remote File Inclusion) in ASP applications because there is no easy way to introduce such vulnerability in ASP. You can't see code execution problem ( such as eval() ) in ASP.NET applications because there is no easy way to do it however in Classical ASP you have this problem. Heck, in PHP application even preg_replace can evaluate code with /e modifier. And yes that happens in real world application, PHPBB was vulnerable to this.

Framework specific problems matter.

Secure by Default - Design of the Framework

Some part of some frameworks designed in a "secure by default" way. For example it's quite rare to see HTTP Header Injection (CRLF/HTTP Response Splitting) problems in ASP.NET because by default all related .NET functions will not accept new lines. Therefore as a developer you should push your limits to introduce this vulnerability, yet if you are stupid enough you'll succeed. Developer's stupidity is something that a framework can't fix. Sorry about that.

Stupid features of a framework can hurt as well. For example Magic Quotes in PHP. Loads of application burned by that, it's such a mess. It shouldn't have been there in the first place that's why finally they decided to deprecate it.

Inbuilt Security Features

I think everyone knows that rolling your own crypto is idiotic but somehow it's OK for people roll their own CSRF protection, SQL Injection filter, XSS protection library etc. Yet all penetration testers observe that these developers keep failing miserably. That's why projects like ESAPI should be employed by more developers.

When it comes to frameworks some of the questions we need to ask;

• Does it support parameterized SQL Queries?
• Does it provide a way to separate data and the HTML and carry out the required encoding based on the output location?
• Does it provide a secure session implementation?
• Does it provide a secure authentication mechanism?
• Does it provide a secure way to execute OS commands? (separating parameters and the executable to avoid injections just like parameterized SQL Queries)
• Does it provide secure storage options? Path normalization functions?
• Does it provide a way to avoid email header injections?
• Is there any function which can protect against new line injections to write safe logs without worrying about new lines?
• Is there any inbuilt feature to apply whitelisting on inputs?

I can go on but you got the point. Unfortunately there is no framework which does all but some frameworks are clearly better.

Take a look at Secure Web Application Framework Manifesto for many other ideas and see what frameworks should bring to the table in means of security by default and as inbuilt security features.

Also ASP.NET's built-in membership feature is also is the right direction and more frameworks should do the same.

Documentation, Culture, Sample Code etc.

Documentation and culture around a framework also quite important. Take a look at Tomcat JSP examples and IIS 6 ASP examples. All of them have several serious vulnerabilities out of the box. Like it's not enough to write vulnerable applications as samples they even deployed them by default so your environment can be vulnerable by default!

For example many examples in .NET documentation uses parameterized SQL Queries which is very good thing although .NET documentation got so many other flaws and terrible code snippets in many places. Generally most of the vendors are terrible about documentation and providing secure code snippets. Some of these sample codes stripped from security checks as they stripped from error checks to increase clarity in the example. I still not a good enough excuse.

Finally when it comes to the culture there are some factors such as what are the best practices among developers. For example you can see more OS Command Injections in Perl applications than potentially any other framework because that's how Perl guys roll. Pass it to an OS command, parse the output and spill it out to the screen. This is a quite rare practice in many other frameworks*.

Required Time, Effort and Knowledge for a Secure Application

All of these discussed factors affect the required time, effort and required security knowledge to develop a secure application.

If framework provides built-in security for CSRF with one line of code than it decreases the complexity of the application, required development and testing time. Finally developers don't need to be a security expert to implement such a check.

Do you really think a junior developer would know that it's possible to do CSRF against a web service. Believe me they don't. Also they don't know that you can do XSS in CSS, they don't know if content-type is "plain/text" XSS is still possible in IE, they don't know that they need to mark cookies as secure, they don't know you can bypass many *clever* XSS protections by using XSS Tunnel or BeeF, they know jack-shit about security especially when it comes to corner cases.

They don't know and they will never know many of these and I don't expect them to know** , that's why framework should care of this stuff and that's why framework matters.

Framework Matters

Now please don't tell me that framework doesn't matter because it bloody does. However the problem is; there is no perfect framework and there won't be anytime soon although it's getting there. Right now you can still choose a better framework instead of choosing arbitrarily by claiming that all of them are same anyway.

My examples were mostly about PHP, ASP and ASP.NET because those are the frameworks that I'm pretty familiar with. You can think of many other frameworks such as Ruby on Rails, Struts or CppCMS and observe similar benefits or framework specific problems.

* Although I need to note that due to many other configuration requirements that task might not be that easy in some frameworks hence not that popular. For example .NET might require several permissions to properly run an executable from an ASP.NET script.

** OK, they need to know about "Secure Cookies" but funny enough many of them still don't. So why not mark all cookies set over SSL as secure and when their code doesn't work they can fix(!) it, at least this way it'll be secure by default and maybe developer will ask herself "What the hell is a secure cookie? and why would I need it?"

Geçen gün Timecrimes - Los cronocrímenes i izledim. Film boyunca eğlenceli bir süreç var, süreç devam ediyor, ediyor, ediyor ve film hiç bir sonuç olmadan aynı Lost’ un bölüm sonu gibi havadaki soruları da cevaplamadan bitiyor. Bu noktayı görünce ben tabii ki ağzımda sonu hiç bir yere bağlanmayan eski Türk filmi tadı kalmış şekilde küfrediyorum.

Timecrimes’ta benim için diğer sofistike olma taklidi yapan filmler arasında yerini alıyor. Başka neler var o listede? Cube serisi başı çekiyor o kesin ama Matrix’te listenin dibinde bir yerlerde, arada da onlarca adını bile hatırlayamadığım film var. Hani şu altında bir çok anlam varmış gibi yapan ama aslında yönetmeninin bile ne halt olduğunu bilmediği filmler. Zaten bu filmler de Deus ex machina da vardır hep, bir şey vardır ama o bir şey hep şeydir çünkü yazar ve yönetmen onu tam anlamıyla sıkmıştır (TDK daki 8. anlamında sıkmak).

Şimdi kimi der ki filmin sonu değil süreci önemli ben film boyunca eğlendim, kimi de derki aynı bir fıkra gibi bir çok filmin süreci sadece son andaki espriye hazırlıktır eğer son anda bir espri yoksa o süreç sadece adama batar.

Şimdiye kadar okuduklarınızdan anlamışsınızdır ki benim sanatsal film kültürüm düşüktür. Elephant gibi “sanat filmlerini“ izlemem hasbel kader izlediğimde de sevmem. Buradaki teori bir çok şeye uygulanabiliyor, bir şey tüketirken süreçmi yoksa ağızda kalan tat mı önemli diye.

Hmmm ilginç bu blog da bir çok gıcık olduğum film gibi hiç bir sonuca ulaşmadı…

Mükemmeliyetçilik hakkında çok konuştum daha fazla konuşmayı planlamıyordum ama orada bahsetmediğim çok önemli bir konu daha var.

Bir sorunu çözerken, ya da bir işi yaparken genelde programcılar işi ya yapabilir ya da yapamaz, arası yoktur, en azından genelde olmadığını düşünürler. Eric Sink bu sendroma Binary Thinking adını vermiş.

Bu mükemmeliyetçilik ile bire bir ilgili bir konu, anlaşılması gereken hemen hemen her çözümün üç şekilde sonuçlandırılabilmesi:

1. Tam bir çözüm – 1
2. Çözememek – 0
3. Yeterli Çözüm

Mesela Google arama motoru olayını çözmedi ama yeterli kadarını çözdü, bundan sonrası düzenli bir şekilde geliştirme aşamasında. Aynı şekilde kullanıcılarınızın %90'ını tatmin edebilecek ya da %90 durumda iyi çalışacak bir çözüme ulaştıysanız kalan %10'u çözmek eğer zorsa çözmeyebilir ve çözmeden de neredeyse aynı verimi alabilirsiniz.

Bu teknik ve teknik olmayan alanlarda düzenli şekilde karşımıza çıkan bir durum, üçüncü seçeneğin orada olduğunu bilmek lazım. (ek olarak bakınız "good enough software")

Herşeyden önce 317 fanboy bana “Özgür Yazılım, Açık kaynak kod’ dan sen ne anlarsın? Höttörö ve töttörö” demeden önce benim bir sürü GPL, LGPL, WTFPL kodumun piyasada bulunduğunu söyleyeyim. Aynı zamanda ticari yazılımla da uğraşıyorum. Dolayısıyla çitin iki tarafında da bulunmaktayım. Bu hala işin felsefesinden anladığımı kanıtlamıyor tabii ki sadece gıcıklığına bu yazıyı yazmadığımı söylemek istiyorum.

Artık gelen yorumlardan o kadar korkmaya başladım ki her yazının başına böyle bir şey yazma gereği duyuyorum…

Özellikle son zamanlarda açık kaynak kod projelerinin destek ve geliştirme ekipleri dikkatimi çekmeye başladı, klasik senaryo:

Kullanım hatası yüzünden yazılım çalışmaz ve kullanıcı bunu geliştiricilere/support’ a sorar:

• Ticari Yazılım:
  ”O sistemin doğru çalışması için parametrelere –X i de eklemeniz lazım.”
  
  Daha sonra da oturup dizaynda nasıl bir değişiklik yaparsak insanlar –X eklemeleri gerektiğini doğal olarak farkederler diye düşünürler. Ya da –X i eklemeyince hata veren yerlere neden ve nasıl –X eklemeleri gerektiğine dair bir mesaj eklerler.
  
• Beleş Yazılım (açık, özgür, parasız vs.)
  ”RTFM kardeşim, –X i eklemezsen o çalışmaz, kaç defa yazdık burada.”

Aynı süreç bilinen bugları raporlama da oluşur. İstisna yazılımlar iki kategoride de var ama bu pattern o kadar yaygın ve rahatsız edici ki farketmemek mümkün değil.

Başvuran ve ilgilenen herkese teşekkürler aradığımız arkadaşı bulduk, Henüz başvuranlara email’ları gönderemedim umarım bu hafta içerisinde onu da göndereceğim.

Netsparker’ ın geliştirme ekibine katılacak yeni bir arkadaş arıyoruz, bu arkadaş yoğun bir şekilde benimle birlikte çalışacağından dolayı ilanı direk buraya yazdım.

Netsparker' ın geliştirme ekibinde bizimle birlikte çalışacak:

• Web güvenliği konusunda kendisini geliştirmek isteyen,
• Evinden (Home Office) çalışacak
• Part-time (haftanın belli günleri ya da belli saatleri)
• Stajyer, öğrenci, kariyerine yeni başlayan ya da güvenlik sektörüne geçmek isteyen

bir arkadaş aramaktayız. Maaş dolgun olmayacaktır.

İş Tanımı

• Netsparker' ın Q/A testlerini gerçekleştirmede yardım edecek
• Güvenlik açıklarını bulup bulmaması konusunda analizler yapacak (bu konuda gerekli eğitimi biz vereceğiz)
• Q/A ile alakalı bir dizi başka iş yapacak

Gereksinimler

• İyi derecede teknik bilgi

Olsa güzel olurlar

• İngilizce (özellikle okuma)
• Web ve Yazılım geliştirme bilgisi (hangi dil olduğu önemli değil)
• Web güvenliği bilgisi

İletişim

CV ve bir giriş yazısını şu email adresine atabilirsiniz : ferruh-at-mavituna.com

Email' ın konu başlığı [CV] AD SOYAD şeklinde olmalı. CV’ lere eğer varsa referans eklemeniz çok işe yarayacaktır.

Alım ve iş görüşmelerine CV’ ler gelir gelmez başlayacağız.

Detaylara inmeden şu konuda anlaşalım: "Yanlış karar almak, kararsızlıktan daha iyidir". 10 senenin ardından diye kısa bir yazı yazmıştım aynı temada devam edeyim.

Uzun süre bulunduğum projelerde bir çok teknik veya teknik olmayan çıkan ürünü etkileyecek özellikler, dokümantasyon, kodlama vs. ile ilgili tartışmaya girdim, saatlerce ince detaylar üzerinde konuştuk, en iyi kararları vermeye çalıştık. Ancak sonraları fark ettim ki aslında kimsenin umurunda olmadığı saçma sapan şeyler üzerine saatlerce efor harcamış, tartışmışız. Eğer eşşek* kadar bir firmaysanız o zaman böyle saçma işler ile uğraşıp 8 kişi bir tane buton tasarlayabilirsiniz o da muhtemelen bir şeye benzemez ama küçük bir firma veya tek kişilik SWAT ekibiyseniz vaktinizi harcayacak daha iyi yerleriniz var.

Yanlış anlaşılmasın genelde birlikte çalıştığınız kişi ürün geliştirme hakkındaki kararlarda ateşli tartışmalara giriyorsa bu genelde iyi bir şeydir. Gerçekten yaptığı şeyi umursuyor, yaptıktan sonra gururla onu herkese gösterebilmek istiyordur, aksi takdirde "salla gitsin" der ve uğraşmazdı.

Bu yazıyı çok daha uzun yazmayı planlıyordum ama sanırım şunu yazmak yetecek:

"Önemli olmayan konularda vaktinizi harcamayın, kararı ertelemeyin, bir karara varın ve yapın. Bu tip kararların %99.99 u daha sonradan değiştirilebilir."

*eşek kadar değil eşşek kadar yani çok büyük

Bilişim sektöründeki iş hayatım 10 seneyi geçti, hala Küçükyalı’ da küçük ve yer yer çiğ köfte yapılan bir ofiste B2B sitesi yazmaya çalıştığımızı, dotmatrix yazıcılardan web monkey makaleleri bastırdığımı, okula giderken bu makaleleri okuduğumu, her defterime başka bir internet projesinin dizaynını, planını yaptığımı hatırlıyorum.

Güzel günlerdi, bilgiye açtım, materyal yoktu, etrafta anlayan adam yoktu, gelen herşeyi tüketiyordum, Amerika’ya iş yapıp karşılığında Amazon’dan kitaplar aldırıyor, sadece internete erişebilmek için ofiste kalıp, klavye başında uyuya kalıyordum. Gençtim ve salaktım ama güzel günlerdi.

Bu 10 sene boyunca düzenli olarak aklıma gelen tek şey eskiden ne kadar salak olduğumdur, sanırım ne kadar çok bilmediğimi düzenli bir şekilde öğrenmeye devam ettikçe seneler bilgi ekliyor gibi değilde eksiltiyor gibi hissettirmeye başladı. İkinci önemli husus ise bilginin ne kadar geçici olduğu, ilgilenmediğim konuların teknik detayları birer birer aklımdan silindi ve elimde sadece temelleri kaldı, hatta o kalanlardan bazılarının temelleri bile değişti.

Tarih bir şeyi kanıtladı ki doğru insanların nasihatlerini dinlemek ve deneyimlerinden faydalanmak önemli bir şey. Ben şahsen gereğinden daha çok deneme-yanılma yaptığıma inanıyorum, bunun iki nedeni var, 1)dinleyecek veya “mentor” diyebileceğimiz kişilerin piyasada, etrafımda olmaması, 2) Salak gençlik ateşinin verdiği herşeyi biliyorum havası.

Yeni nesil yeni bir internet ile karşı karşıya, herkes yazıyor, çiziyor her ne kadar herkes yazıyor olsa da takip edecek deneyimlerinden faydalanacak her konuda binlerce insan var. Sağolsunlar bizleri kendi yaptıkları hataları yapmaktan kurtarıyorlar.

Son olarak bulunduğunuz yerlerin kültürü çok önemli, doğru iş yerinde, doğru ekiple güzel kültürlerde bulunma Fikir Üretme ve Etki Tepki konusundaki gibi doğru adrese yönelmeyi sağlıyor, bugüne kadar farklı yerlerde teknik olarak kayda değer bir şey öğrenmemişimdir belki ama teknik olarak herşeyi değiştiren farklı kültürleri, çalışma yöntemlerini öğrendim, değişik karakterler ile tanıştım. Bunun yerini hiç bir şey tutamaz.

Muhtemelen on sene sonra tekrar bu yazıyı okuyup gülecek ve ne kadar salakmışım diyeceğim…

Netsparker’ ın ücretsiz Community Edition’ ını yayınlamış bulunmaktayız,

• Digg’ e gönderin , Reddit’ e gönderin
• Download Edin 

İlerleyen günlerde fırsat bulunca daha detaylı bir blog post daha yazacağım.

Sanırım ilk defa bir kitapta okumuştum, yeni bir ürünün yeni bir özelliğinden bahsediyordu geliştiricisi ve ön plana çıkan bir özellik için "It was the next obvious step" demişti. Çok basit bir cümle olmasına rağmen bende bir ışığın yanmasına neden oldu. Bir sonraki bariz adım. Çünkü elimizdeki süreçlerin bir çoğu belli, hiç bir şey bir gecede çıkmıyor, genelde beslendiğimiz kaynak aynı.

O zaman fark ettim ki önemli olan on sene sonrasını tahmin edebilmek değil "bir sonraki bariz iş" i görebilmek ve diğer görebilenlerden önce yapabilmek.

Gene bu yüzden bana biri bilmediği bir konuda proje getirince ya da bahsedince pek dikkate almıyorum, çünkü o kişinin o sektör hakkında hiç bir fikri yok, her ne kadar bu ona daha serbest bir düşünce şansı tanısa da %90 o işi beceremeyecek. O sektörün bir sonraki adımlarını takip etmesi mümkün değil, çünkü önceki adımlar hakkında hiç bir fikri yok. Gene aynı nedenlerden dolayı 2000' li yıllarda bilişime başlamış herkese şiddetle Accidental Empires kitabını (ya da belgeselini) öneririm, bu sayede bu sektörün nereden, nereye, kimler ile ve nasıl olaylarla geliştiğini görebilirler.

Aynı borsada hisse senedi tanımak gibi, bir hisse senedinin ne kadar tanırsanız, geçmişini ne kadar biliyorsanız başına gelebilecekleri daha rahat tahmin edebilirsiniz. Mesela geçen senenin başında krizlerden sonra sağlam bankaların hisselerinin uzun bir süre yükselişte olacağı barizdi çünkü ya batacaklardı ya da çıkacaklardı, nitekim aylarca tüm banka hisseleri yükseldi.

Bunun yanında "Black Swan" teorisi her zaman orada olacak ama açıkçası bu teori hiç bir şeyi değiştirmiyor, aynı yarın uyandığınızda evinize bir uzay gemisi girmesinin umurunuzda olmadığı ya da buna karşı hazırlık yapma gereği duymadığınız gibi.

Sektörün her noktasına baktığınızda bir sonraki bariz adımı çok rahat görebilirsiniz, YCombinator' un yeni 26 startup' ına bir göz atın kaç tanesi gerçekten orijinal, hemen hemen hiç biri, hepsi bir sonraki bariz adım...

Umarım zaten hepiniz neden bir yapılacaklar listesi tutmanız gerektiğini biliyorsunuzdur, özetlersek:

• Ne yaptığınızı bilmek
• Ne yapacağınızı bilmek

ama en önemlisi:

• Binlerce şeyi aklınızda tutmak yerine bir yere not alıp beyninizden silmek

Bu son maddenin önemini yıllarca anlamamıştım, yeni yeni anlıyorum. Eğer yapılacak bir işi bir yere not almadıysanız o iş her zaman aklınızda kalacak, aynı çözemediğiniz bir bilmece ya da nedenini bulamadığınız bir bug gibi. Dolayısıyla yaptığınız işe odaklanabilmek için  o an yapmadığınız her şeyi, aklınızdan çıkarmanız lazım. Bunun da en pratik yolu bir yapılacaklar listesi tutmak.

Yapılacak listesi tutmak

• Sistem belli olmalı ve güvenlir olmalı
  Hep aynı sistemi kullanın, küçük bir defter, todo list, tada list, remember the milk, sekreteriniz vs. Ne olduğunun önemi yok ama güvenilir ve pratik olmalı.
  
  
• Listenizi açıklayıcı bir şekilde yazın
  Asla ve asla anahtar kelimeler yazıp ne de olsa sonra hatırlarım demeyin, zaten bu işin amacı aklınızdan bu konuyu çıkarmak. Aynı kod yazarken başka bir objeye verdiğiniz referansı silmezseniz memory leak olacağı gibi beyninize de o iş ile ilgili anahtar kelimelerden referanslar kurarsanız o iş aklınızdan tamamen çıkmayacak. Ya da aklınızdan çıkacak ve o işe tekrar döndüğünüzde o işin ne olduğunu hatırlamayacaksınız.
  
  
• Adımlı detaylandırma
  Özellikle teknik konularda bazen listeye yeni bir madde eklerken çok fazla detaylara kaymak mümkün olabiliyor. Mesela “Blog’ a CAPTCHA ekle” maddesinin altında teknik olarak nasıl bir CAPTCHA kullanacağınızı dokümante etmenize ya da düşünmenize gerek yok. Bunu o maddeye gelince detaylandırabilirsiniz. Özetle önce ana notu alın, ondan sonra o işe geldiğinizde elinizdeki işi maksimum 2 saatlik yeni parçalara bölün. Eğer bir parça iki saati geçiyorsa muhtemelen gereğinden büyük bir parçadır demek ve onu da küçük parçalara bölmelisiniz. Bu yüzden ben ağaç yapısı ile girdi desteği olmayan bir todo list yazılımı kullanamıyorum, bence bu çok önemli.
  
  Çok büyük parçaları yapmaya çalışmak kötü sonuçlar verecektir. Mesela “Yeni CMS sistemi yaz” gibi bir madde tamamen işe yaramayan bir maddedir. Çünkü bu işin altında ne yapacağınız belli değil, ama bunu 2 saatlik işlere bölerseniz tam olarka ne yaptığınızı biliyor olacaksınız. Mesela “Database’ i tasarla”, “Yeni üye kayıt sayfasını yaz” vs.
  
  
• Revize edin
  Düzenli bir şekilde listenizi gözden geçirin, bazı şeyleri hali hazırda yapmış olabilirsiniz, hemen listeden silin. Bazı şeyler artık gereksiz olabilir, hemen listeden silin vs. Ne kadar güncel olursa o kadar iyi çünkü bu sizin sisteminize güveninizi arttıracak bu da beyninizi rahatlatacak.
  
  
• Önem  Sırası
  Yapılacaklar işler listenizde her bir işin ne kadar önemli olduğunu bilmeniz gerekli. Eğer işlerin önemi belli değilse planlama yapamazsınız ya da “Yeni üye kayıt sayfası“ nı bitirmeden “Google Maps API ile twitter’ ı bağlayıp, iPhone’ dan site hakkında twit gönderen kişilerin pie chart’ larının gösterilmesi“ işini yapıyor olursunuz. Ben bunu çok yaptım, klasik hata. Teknik konularda bu önem oranı 1-10 arası olabilir, genelde 1-3 arası o kadar iyi çalışmayabiliyor.
  
• Kaynama yapmayın
  Bazen çalışırken aklınıza bir şey gelecektir eğer çalıştığınız konu ile bire bir alakalı önemli bir şey değilse onu yapılacaklar listenize alın ve daha sonradan o işe geçin. Direk o işe zıplamayın ya da önemsiz işler için zaten bu işi yapıyorum onu da aradan çıkartayım diye düşünmeyin.

Çalışırken şu 2 soruya cevap veriyor olabilmeniz lazım:

1. Şu an tam olarak ne yapıyorsun ve niye? Neyin parçası, hangi işin bitmesine nasıl yardımcı olacak?
   “Kod yazıyorum” ya da “CMS yazıyorum” geçerli bir cevap değil, Doğru cevap “CMS’ i bitirmem için gerekli olan yeni kullanıcı kaydı sayfasının girdilerinin client-side kontrolü için JavaScript yazıyorum” olmalıdır.
   
   
2. Bundan sonraki adımlar neler?

Senelerce bir çok farklı işte çalışıp küçüklü büyüklü bir çok proje yaptıktan sonra fark ettim ki bir projenin en büyük düşmanı içimizdeki diğer projeler. Ne zaman bir işe başlasam daha henüz başındayken başka projeler gelip odağımı çalıyor.

Başka projelerin odağı çalması tamamen motivasyon ile alakalı. Eğer elinizdeki iş henüz yayınlanmamışsa, yayınlanmışsa ama henüz yeterince kişi ilgilenmediyse, beklediğinizi bulamadıysanız başka projelerin odağınızı çalması çok daha basit hale geliyor.

Bunu çözmek için bir kaç yol:

• Projelerin ayağa kalkmasının belli bir vakit süreceğiniz kabullenin. Bu vaktin genelde sandığınızdan daha fazla süreceğini de bilin.
• Aklınıza gelen tüm diğer fikirlere şiddetle karşı çıkın
• Bu fikirleri bir yere not alıp, unutabilirsiniz
• Bu fikirleri blog, twitter gibi yerlerde açık açık dokümante edip kurtulabilirsiniz

Her zaman "süper" fikirler aklınıza gelecek, bunu durdurmak mümkün değil ama o fikirleri kovalamamak mümkün.

İyice Odaklanın

Elinizdeki işe odaklanmak için diğer tüm gereksiz projelerden, işlerden de kurtulmanız lazım. Vaktinizi veya aklınızı alan gereksiz tüm projelerinizi ya elden çıkartın ya da çizgi çekin.

Elden çıkart: Sat, kapat.
Çizgi Çek: Bir daha dokunma, güncelleme, tanıma.

Nasıl birden çok şeyi aynı anda yapmaktan iyi verim alınamıyorsa, birden çok projeyi aynı anda yapmak da işe yaramıyor.

Son günlerdeki öğreten adam temama yıllardır yazmak isteyip bir türlü yazamadığım bu yazı ile devam ediyorum...

Blog yazmaya başladığım ilk günden bu yana düzenli soru e-mail' ları alıyorum. "Hangi antivirüs' ü alayım?" dan tut "Erkek arkadaşım bilgisayarı benden çok daha fazla seviyor ne yapayım?" a kadar. Ciddiyim ikinci soru ve farklı varyasyonlarını bir kaç defa gördüm.

Kişisel sorulardan hiç bahsetmiyorum bile...

Henüz daha toyken hemen hemen tüm bu emaillara cevap veriyordum. Daha sonradan fark ettim ki bu emailların yarısı cevabı bile hak etmiyor. Ben de bizzat tanımadığım kişilere email ile soru soruyorum, bunların bazıları çok meşgul ya da günde 100 tane email alan kişiler. Kitap yazarları, teknik adamlar, blog yazarları vs.

Bu soruları sorarken şu kuralları izlemeye çalışıyorum:

Altın Kural
Soru sorduğum kişi bana cevap vermek zorunda değil.

Kural 1
Kendi yapabileceğim bir şeyi başkasından istemem. Mesela Google' da arama yapmak gibi!

Kural 2
Sorduğum sorunun cevabını verecek kişinin eforunu minimuma indirmem gerekiyor.

• Soru hakkında kişinin neleri bilmesi gerektiğini düşünüp bunların hepsini daha o istemeden ilk emailda göndermeye çalışırım. Dolayısıyla sorduğum kişi bana dönüp 10 soru daha sormak zorunda kalmaz.
  
• Emailı mümkün oldukça kısa tutmaya çalışırım. Kısa yazı yazmak kolay bir iş değil, dolayısıyla göndermeden sorunun üzerinden defalarca geçip yeterince kısa mı?, anlatmak istediğimi en efektif şekilde anlatabildim mi? diye düşünürüm.
  
• Emailları adam gibi dil bilgisi ile yazmaya çalışırım. Yazım kuralları olabildiğince doğru olmalı. En azından bir "spell checker" kullanalım değil mi? Eğer ben yazdığım emaila 5 dakika harcayamıyorsam cevap verecek kişi neden 20 dk. uğraşıp cevap versin ki?

Kural 3
Kibar ol. Bkz: Altın Kural

Tanımadığınız insanlara tanımadığınız insanlar gibi yaklaşın. Askerde birlikte bot bağlamış gibi değil. Burada herkesin tipi farklı tabii ki, benim blog üslubumdan dolayı genelde aldığım emaillarda insanlar senli-benli hitap ediyorlar ki bence hiç bir sorun yok, hatta siz diye gelen emaillar biraz tuhafıma gidiyor ama bu durum herkes için geçerli olmayacaktır.

Buna rağmen daha kendinin kim olmadığını söylemeden, selam sabahsız emaillarda genelde anında siliniyorlar. Aradaki farkı iyi bilmek lazım.

Kural 4
Karşıdaki kişinin konusu ile alakalı bir şey sormaya çalışırım.

Mesela bana Java konusunda teknik sorular geliyor. Acaba bugüne kadar Java' yı küfretmek dışında cümle içerisinde kullandığımı kaç defa görmüşler ki?

Kural 5
Elimden gelen her şeyi yapmama rağmen kişi cevap vermezse kızmam. Dolayısıyla emailları yazarken varsayılan olarak cevap almayacağımı düşünürüm, cevabın gelmesi beni sevindirir. Bkz: Altın Kural

Altın Kural, altın kural, altın kural.... Karşıdaki kişi bana cevap verme yükümlülüğünde değil bana cevap veriyorsa bu büyük bir kıyaktır. Bunu unutmadan yazdıktan sonra gönül rahatlığı ile bir yabancıya email atıp soru sorabilirsiniz.

2008’ de RIATalks’ da flash güvenliği ve web 2.0 uygulamalarının güvenliği üzerine konuşmuştum.

Sanırım daha önce kimsenin pratikte bunu görmemiş olmasından dolayı özellikle Flash sunumunda gösterdiğim Crossdomain.xml’ i exploit etme işini herkes çok beğendi. Bu sunumdan sonra özellikle bir çok güvenlikçi arkadaşım bunun kodunu istemişti, ben de kodları kaybettiğimden dolayı verememiştim. Bugün backup’ larım arasında buldum bu kodları. Kodlar, sunum ve sunumun videosu aşağıdaki gibi.

Video

Sunum

Kod Download

http://drop.io/ycek5is

Her zaman insanları okumak konusunda iyi olduğumu düşünmüşümdür ve bu hislerime güvenmediğimde başıma gelenlere bakarak sandığımdan daha da iyi olduğumu söyleyebilirim, ama zaten kendi hakkımızda ne biliyoruz ki?

Eğer birine Evet / Hayır noktasına gelebilecek bir soru sorarsanız iki farklı bilgiye dayalı iki farklı cevap gelme ihtimali var.

Mesela "Zafer evde mi?"

• Evet, Zafer evde. Çünkü cevap veren kişi Zafer' i az önce evde gördü.
  
• Hayır, Zafer evde değil. Çünkü cevap veren kişi Zafer' in evden çıktığını ve geri gelmediğini gördü.
  
• Evet, Çünkü cevap veren kişi Zafer' in evde olduğunu tahmin ediyor, çünkü kendi çapında nedenleri var ama aslında Zafer' in evde olup olmadığını bilmiyor.
  
• Evet, Çünkü cevap veren kişi Zafer' i gördüğünü zannediyor ama aslında hayal gördü, dolayısıyla tüm dürüstlüğüyle cevap veriyor ama aslında Zafer evde olmayabilir.

Genelde bir kişi cevabı malum yerinden atıyorsa bunu anlamak pek zor olmuyor, ki bu durumda ilk işim kanıt aramak oluyor "Zafer' i en son ne zaman gördün?" , "Eve kaçta geldi?" vs.

Örnek olarak basit bir konuyu seçtim, ben aynı diyalogu bir çok konuda yaşadım. Normal diyaloglarda insanların bunu yapmasına çok alışkınım, mesela saçma bir istatistik konusunda sanki kendileri 1000 kişi ile bizzat röportaj yapmış gibi konuşurlar. Kendilerine kaynak sorunca Hürriyet' i, amcalarının oğlu Muzaffer' i ve Wikipedia' yı gösterirler ama aslında konu hakkında sadece fikirleri vardır, buna rağmen cevapları her zaman kesindir.

Aynı komik diyalogu tarih kitaplarında da zaman zaman görülür "Padişah zötterö kendisine hastır oradan diye yeni çerinin ağlamasına kulak asmadan Mehmet ve Ahmet ile birlikte, zöttöre ağacında sallandırdı, çünkü Katerina onu gaza getirdi." Tarihçilere sorduğunuz da çok gülerler bunlara.

Açık konuşmak gerekirse bu tip kesinlikle bir şey aktaran ya da cevap veren insanların becerilerine hayranım, çünkü gerçekten bilmediğin bir konuda kesin konuşmak etkileyici bir yetenek ve iş dünyasında adam kafalamaya çok yarar, tabii ki karşında senin bunu attığını ya da gerçekten yeterli derecede bilmediğini anlayabilecek birisi yoksa. Bkz: fizzbuzz yazamayan programcı işe alan bir dünya firma.

Buna rağmen özellikle teknik konularda bunu yapmak feci bir hatadır. Ben birlikte kod yazdığım birine 10.000 elemanlık bir datayı "SortedList" te mi daha hızlı buluruz yoksa "List" te mi dediğimde kişinin cevabı ya "SortedList" ve "List" bilgisinin çok iyi olmasına dayanmalı ya da kendi bizzat bu işi denemiş ve benchmark' larını yapmış olmalı. Aksi takdirde "Bilmiyorum" ve "Emin değilim" dışında vereceği tüm yanıtlar faydadan çok zarara neden olacaktır.

Özetle tahmin ettiğiniz şeyler konusunda denemeden "Budur" ya da "Değildir" demeyin, ya da bunu söylerken çıkış datanızı belirtin. Benimle çalışmış olanlar bilirler genelde bir bilgi elime ulaşır ulaşmaz, bir sakatlık olduğunu hissedersem klasik sorularımdan biri şudur "Neye dayanarak?", bakalım boktan bir dayanak noktan mı var? Yoksa gerçekten söylediğini biliyor musun? Bazen söyleyen kişide bunu irdelememiş olabilir, normaldir, siz söyleyince düşünür o da hak verir.

İlginç bir şekilde bunun insanlar arasında inanılmaz yaygın bir davranış olduğunu gördüm, bizzat ailem, akrabalarım bir sürü arkadaşım hepsi bu şekilde ve şahsen beni deli ediyorlar. İlginç bir şekilde sanırım işin doğal bu. Eğer %50 üzerinde bir şeye inanıyorsan %100 biliyormuş gibi "Evet" veya "Hayır" deme hakkına sahipsin. Normal hayat üzerine bir uzmanlığım yok ama teknik konularda bunu yapıyorsanız ciddi sorunlar var demek.

Masanın söyleyen tarafındaysanız söylediklerinizi ve söyleyiş biçiminizi iki defa düşünmeye başlayın eğer dinleyen kısmındaysanız "all input is evil until proven otherwise" deyişindeki gibi gelen girdinin doğruluğunu onaylayın ve insanların tonundaki o emin olmama tınısını tanıma konusunda kendinizi geliştirin.

Bu aralar "öğreten adam" modunda yazmaya başladığımı fark ettim, buradaki her yazı benim naçizane deneyimlerimin çıktısıdır (doğru, yanlış, hatalı), ben kendi kişisel balonumdan yayın yapıyorum, öyle kabul edile.

Dün bir e-mail aldım, bir arkadaşımız şöyle bir soru sormuş:

"Kendini bu kadar nasıl motive ediyorsun?"

Her şeyden önce motivasyon insandan insana inanılmaz derecede değişen bir şey. Kimi insanı motive etmek için gaz vermeniz lazım, kimi insana ödül göstermeniz lazım, kimisine küfretmeniz, hırslandırmanız lazım vs. vs. Mesela çoğu insan baskı altında daha iyi çalışırken ben baskı altında genelde dökülürüm ve iş yapamam.

Sizi sizden iyi bilen biri yok. Bu konuda ilk iş kendinizi neyin tetiklediğini öğrenin, hayatınız boyunca kendinizle yaşadınız, herhalde daha önceden hangi faktörlerin sizde çalışma isteği uyandırdığını bulabilirsiniz.

Motivasyon bir kaç faktöre bağlı, benim gözümde 2 ana faktör var ve onları etkileyen 2 önemli parametre var:

Faktör I - Ödül

Mesela açık kaynak kodlu bir uygulama yazıyorsanız, 2-3 ödül olabilir:

• Programlama becerilerinizi geliştirmek
• Aynı sektörde daha fazla insan ile tanışmak
• CV' nize güzel bir şeyler eklemek yani daha iyi bir işe girmek
• Dünyadaki bir eksiği tamamlayıp insanlığı ve teknolojiyi bir adım ileriye götürmek (!)

Faktör II - İhtimal

Eğer size günde iki saat çalışarak bir sene içerisinde ciddi bir futbol takımında oynayabileceğiniz garantisini verebilseydim, siz de bu konuda ciddi derecede motive olurdunuz, çünkü ödül büyük, çalışma mantık dahilinde ve sonuç kesin.

Gerçek hayatta sonuç hiç bir zaman kesin olmuyor onun yerine ihtimaller üzerine konuşuyoruz. Mesela yukarıdaki örnekten devam edersek açık kaynak kodlu bir yazılım yazdığınızda eğer bir sene içerisinde toplam üç milyondan fazla kullanıcıya ulaşabileceğinizi bilseydiniz bu tip bir uygulama yazarken çok daha motive olurdunuz. Tabii ki ödül seçiminizin bu olduğunu varsayıyorum, eğer derdiniz para ise üç milyon kullanıcının yüz bininin paralı bir destek alacağını umuyor olacaktınız vs.

Olaya gel, geyiğe bağladın gene

Bunlar haricinde ödül' ü etkileyen ödülün size ne anlam ifade ettiği faktörü var. Mesela para size bir anlam ifade etmiyor olabilir ama ünlü olmak çok önemlidir gibi.

Son faktör de ödüle ulaşmak için gerekli efor. Bu kritik çünkü eğer beş sene boyunca günde on iki saat çalışınca başarılı olacağınızdan emin olsanız bile bunu yapmayabilirsiniz. O yüzden gerekli efor da kritik faktörlerden biri.

Psycho Folder

Mesela Psycho Folder isimli küçük yazılımım için benim motivasyonumu inceleyelim:

• Ödül
  Kişisel bir işi çözmek. Bunu çözünce çok büyük bir şey kazanmayacağım. O yüzden ödülün büyüklüğü az.
  
• Önem:
  Bunu çözmek hayatımda ciddi bir değişiklik sağlamayacak, günde bir saat tasarruf etmeyeceğim. Dolayısıyla ödülü çok da umurumda değil.
  
• İhtimal
  Başarı ihtimalim çok yüksek, çünkü yapabileceğimden eminim. Ne kodlayacağımı biliyorum, dile hakimim, teknik olarak ne yapılması gerektiğini biliyorum. 
  
• Efor:
  Çok düşük bir efor ile çıkabilecek bir iş.

Dolayısıyla Psycho Folder için motivasyonum vardı ama iki günde yayınlayıp bitirecek kadar. Artık üzerinde çalışmıyorum, çünkü bundan fazla efor sarf ettiğimde alacağım ödülü karşılamaz hale geliyor.

Aynı mantık üzerinde ilerleyince neden kendi işini yapmayan bir çok kişinin çalıştığı iş yerlerinde motive olamadığını hemen anlıyoruz.

Sonuç

Motivasyon tamamen yaptığınız iş ve faktörler ile ilgili, ben son zamanlarda hayatımda hiç olmadığım kadar motive olmuş durumdayım, çünkü üzerinde çalıştığım proje için yukarıdakilerden ihtimal, ödül ve önem ciddi bir şekilde yükselişte.

Son olarak not düşmek lazım insanın kariyerinde 15m² ofislerde tek ödülü internet ve yazıcıyı kullanabilmek olduğu zamanları da oluyor, ve ilginç bir şekilde inanılmaz bir motivasyonda da olabiliyor, dolayısıyla kariyerin belli noktalarında iniş ve çıkışlar boyunca uzun vade planlara bakıp motive olmak lazım.

Soruya cevap vermedin?

Tüm yazıyı yazmama neden soru şuydu:

"Kendini bu kadar nasıl motive ediyorsun?"

Sevmediğin işi yapma

Her şeyden önce zevk almadığım işleri yapmıyorum, bu yüzden "Efor" faktörüm genelde düşük oluyor, çünkü yaptığımdan zaten zevk alıyorum.

Bazen sevmediğiniz işleri bir süre yapmak zorunda kalacaksınız bu kaçınılmaz, bunu bir adım olarak saymak lazım. Nedenleri maddi olabilir, kariyer gereksinimi olabilir vs. Sadece sevmediğiniz bu işi çok uzun yapmayacağınızdan ve bir planınız olduğundan emin olun.

İnsanları önemseme

Ben çok fazla insana fikir sorarım ama aldığım fikirleri kullanmadan veya onlara inanmadan çok iyi analiz eder ve sorgularım. Kimseden "X böyledir" gibi bir açıklamayı kanıt olmadan kabul etmeyin. İnsanlara neden diye sorduğunuzda bir çok kişinin neden sorusunu cevaplayamadığını ya da saçma bir nedenleri olduğunu göreceksiniz. Hatta bazen onlar nedenlerini söylerken söylediklerinin saçma olduğunu anlayacaklar. Çünkü yıllardır akıllarındaki o fikri tekrar sorgulama gereği duymamışlar.

Ben bir çok insanın aksine fikirlerini, planlarını ve hayallerini paylaşmayı seven ve bu konularda açık olan biriyim. Şahsen yaptığım bir çok kariyer seçiminde çok yakın çevrem harici bir çok insan bana inanmadı. Kimi açık açık söyledi, kiminin söylemesine bile gerek olmadı, belliydi.

Genelde yanıldılar, 6 ayda bir iş değiştirmek iyi bir fikirdi, 15m² lik boktan bir ofiste çalışmak ve kariyerimin başında tüm şerefsizlerle tanışıp daha sonradan şerefsiz ve şerefli insanları 10 dk. içerisinde birbirinden ayırma yeteneğini kazanmak iyi oldu, o firmanın bana kazık atması insanların kişisel yüzleri ile iş hayatlarının farklı olduğunu öğretti, sadece "networking" olsun diye kişisel özelliklerini sevmediğim insanlar ile takılmamak, konuşmamak iyi bir fikirdi... vs.

Özetle insanların %90' ı salaklık bariyerinde, posizyonları, durumları ve popülerlikleri ne olursa olsun. İnsanlar her projenizde bok atacak, laf sokacak sizi demotive edecekler. O durumlarda bu insanların bariyerin diğer tarafında olduğunu kendinize hatırlatın, ben öyle yapıyorum. Bu bazılarına züppemsi gelebilir ama çivi çiviyi söker. Salak insanlara karşı ya züppe olmak ya da salak taklidi yapmak gerekiyor, ona göre duruşunuzu seçin.

Çok dertliymişim bu konuda çok uzattım, özetle:

• Başkalarında bilgi ve fikir kabul edin ama onu analiz edebilecek tek kişi sizsiniz
• İnsanların genelde salak olduğunu unutmayın
• Bir çok büyük ve iyi fikre bir çok insanın kafasının basmaması doğal bir şey, ne kadar zeki olurlarsa olsun, aynı şeyi göremiyor olabilirler. Bazı fikirlerin olgunlaşması için gerekli aynı şeylerden beslenmek lazım.
• Son olarak "kalın kafalı" olmayın bazen gerçekten de haklı olabilirler, dolayısıyla insanlar genelde salak diye subjektifliği kaybetmenin bir anlamı yok.

Hedefleri büyük tut

Benim her zaman adım adım hedeflerim vardır, çok kesin şeyler değil ama kafamda büyük bir planın olması en dandik noktalarda, kısa vade ödüllerinin çok kötü olduğu zamanlarda bile devam etmemi sağlıyor.

JFRI - "Just Fuckin' Release It"

JDI ve JFDI versiyonlarından sonra bu da benim versiyonum JFRI. Bir şey yapıyorsanız ne olursa olsun onu olabildiğince hızlı şekilde yayınlayın. Kapalı bir grupta yayın yapıyor olabilirsiniz ya da tüm dünyaya açabilirsinizö önemli değil ama yaptığınız işi yayınlamak ciddi bir şekilde motivasyonunuzu arttıracaktır.

Bu da benim düzenli olarak yaptığım şeylerden biri, bence "Release Often Release Early" motto' sunun es geçilen en önemli avantajlardan biri budur. Hatta bir çok kişi motive olabilmek için projelerini bloglarında tarih ve detayları ile yazıyorlar. Bu sayede "herkese rezil olma korkusu" onları motive ediyor. Bu benim motivasyon kriterlerimden biri değil "bkz. insanları önemseme başlığı" ama sizin için işe yarayacaksa neden olmasın, kullanılabilir.

Özetle yaptığım işleri en kısa sürede yayınlamaya çalışıyorum.

Felsefe

Son olarak felsefik tipler için ödül konsepti çok havada kalacaktır, çünkü insan ödülü takip ederken hızlı şekilde "Hayatın amacı nedir?" noktasına ulaşıyor. Balıkçı kasabası adamıysanız profesyonel anlamda hemen hemen hiç bir halttan kolayca motive olamazsınız, çünkü ödül' e verdiğiniz önem sıfır olacak. O zaman esas ödülü düşünün ve hayatınızdaki öncelikleri ona göre belirleyip doğru şeylere motive olun.