Typo's

posts/2011-10-15-learn-by-copy-rules-for-ignoring-nih-syndrome.md

@@ -4,25 +4,25 @@ tags: thoughts
 keywords: not invented here syndrome, programming, thoughts
 --
 
-When telling me you are writing a new library, chances are that the obnoxious me is right by replying "It's been done before, just use that". This is a fact of software development, inherrent to the large amount of [code monkeys], cranking out software since 1950's [machine language programs]. Should it stop you from writing it? No! 
+When telling me you are writing a new library, chances are that the obnoxious me is right by replying "It has been done before, just use that". This is a fact of software development, inherent to the large amount of [code monkeys], cranking out software since 1950's [machine language programs]. Should it stop you from writing it? No! 
 
 The above describes a "syndrome" called "Not Invented Here" (NIH) which is generally considered a bad thing. In this post I will show the merits of the syndrome when used for learning concepts, frameworks or programming languages.
 
 ## Understanding
 
-"Not Invented Here" syndrome describes ignoring existent products, research, knowledge or, in our case, software from third parties and creating it your damn self (and than doing it multiple times, therefore the syndrome). The most heard argument against NIH is _"Why you would want te reinvent the wheel?"_. My reply to this is _"Because I want to understand the wheel!"_.
+"Not Invented Here" syndrome describes ignoring existent products, research, knowledge or, in our case, software from third parties and creating it your damn self (and than doing it multiple times, therefore the syndrome). The most heard argument against NIH is _"Why you would want to reinvent the wheel?"_. My reply to this is _"Because I want to understand the wheel!"_.
 
 A few years ago, starting with Django, I decided to build my own blogging software. There were already a dozen libraries doing the exact same thing. But still, I believed this was needed because I wanted to learn the framework and while I could try reading myself to sleep with Django's documentation, finishing a website with it would have me scratching a bold spot within the hour. Contrast this at looking at others people code, while at the meanwhile writing my own. Not only does this enable you to understand the framework at a more fundamental level, it also helps you memorize its tools more effectively.
 
-This understanding precedes the first rule for ignoring the NIH syndrome. __Ignore it when you are learning.__ May it be a new technique, framework or language, you don't understand it untill you use it. You don't understand it untill you complete the process of idea to working implementation. And to dive in using it, create a new project where you have the guidance of an already finished one.
+This understanding precedes the first rule for ignoring the NIH syndrome. __Ignore it when you are learning.__ May it be a new technique, framework or language, you don't understand it until you use it. You don't understand it until you complete the process of idea to working implementation. And to dive in using it, create a new project where you have the guidance of an already finished one.
 
 ## Improving
 
 When I was a year into Django we needed a account managing application for [Bread & Pepper]. The ``GOTO`` application was [django-registration]. At this point I was comfortable with [Python] and [Django] and decided to create my own account application called [django-userena]. This has to do with my second rule for ignoring NIH: **You can do it better**.
 
-This reason should be used cautiously because it can hamper the quality of our professions products when your "do it yourself" attitude stems from a minor modification or improvement towards an _open-sourced_ library. It would therefore be wise to contact the author and propose your changes, maybe it's something they wanted to do themself or already tried and then share their reasons for not implementing it. If you can't work it out together, do it yourself.
+This reason should be used cautiously because it can hamper the quality of our professions products when your "do it yourself" attitude stems from a minor modification or improvement towards an _open-sourced_ library. It would therefore be wise to contact the author and propose your changes, maybe it's something they wanted to do or already tried, sharing their reasons for not implementing it. If you can't work it out together, do it yourself.
 
-If there is no possibility for cooperation on the project that you are improving, go ahead and build a better one. This gives you a benefit of learning from the mistakes of the giants before you and again, improving your own skillset.
+If there is no possibility for cooperation on the project that you are improving, go ahead and build a better one. This gives you a benefit of learning from the mistakes of the giants before you and again, improving your own skill set.
 
 ## Use it for Learning
 
@@ -40,7 +40,7 @@ _Ha_ was working on [django-userena], knowing the framework and creating innovat
 
 ## A Backboard Philosophy
 
-We came full circle on a backboard philosophy on how to become an expert (Ri) programmer. At first, ignore you are reinventing the wheel, rinse and repeat the practice untill you reach the stage of _ha_ where you are familiar with the language, framework and are able to create software that stands on it's own. This time you are able to supply others with code to learn from. Slowly your knowledge will allow you to break free and reach the stage of a _ri_ programmer[^2]. Being a _ri_ programmer makes it more easy to create your dent in the universe with new innovative software[^3].
+We came full circle on a backboard philosophy on how to become an expert (Ri) programmer. At first, ignore you are reinventing the wheel, rinse and repeat the practice until you reach the stage of _ha_ where you are familiar with the language, framework and are able to create software that stands on it's own. This time you are able to supply others with code to learn from. Slowly your knowledge will allow you to break free and reach the stage of a _ri_ programmer[^2]. Being a _ri_ programmer makes it more easy to create your dent in the universe with new innovative software[^3].
 
 [^1]: Tribute to the late Steve Jobs's "We’re here to put a dent in the universe. Otherwise why else even be here?" quote.
 [^2]: There are not many who can claim this title, but one of them is the late [Dennis Ritchie], father of C programming language.