Merge pull request #148 from Zuehlke/feature/igr

Feature/igr #146, #105, #118

articles/dont-teach-kids-programming.md

@@ -0,0 +1,31 @@
+---
+authorName: Igor Spasić
+authorGithubUsername: igr
+issue: 146
+title: Don't teach kids programming
+---
+# {{page.title}}
+
+Programming is becoming more and more in primary schools. This initiative is recognized all around the world - many kids are being taught programming.
+
+Stop! We're wrong! Do not teach children programming!
+
+The assumption is wrong. What we are doing is observing the present and we notice the rising trend of the need for developers. We extrapolate this fact and base the future on it, with the conclusion that the same rules will apply in 10 or 20 years from now; when our children are going to be old enough to work.
+
+If there is something we do not know, that is the future of the world as it is now. The dynamics of the change in the digital industry is so big that there is no pattern which can be applied to it. The amount of information is being multiplied; requirements change faster than ever. The truth is, we have no idea how the world will look in 20 years. In such an environment, programming, unfortunately, is not a "joker" wildcard that will give the heirs a chance to master the future world.
+
+Moreover, programming IT market is looking for is mercilessly monotonous and stumbling. It's all about the skill; programming today is reduced to the framework timing, and less to the science. Do we really want to include children in such anemic world of programming?
+
+Programming should not have a meaning in itself. Programming should become a tool - in fact, only one of the tools that will be available to people. The technical knowledge, which we boast of and so passionately wish to put into young brains, should not be taken as the primary source of knowledge.
+
+Instead, we need to teach children _critical thinking_. In a world without censorship, but with false news, a critical attitude is more important than programming patterns.
+
+We need to teach children _communication_. A world in which everyone has a voice and an opinion about everything requires a precise and clear communication and exchange of ideas and thoughts.
+
+We have to teach children to _work together_. In a world where there are more screens than people, cooperation becomes a necessary ingredient of progress.
+
+And finally, we have to teach the children _creativity_. Creativity is a part of the human definition. Creativity is something we need to constantly stimulate, now more than ever before, because that is the only way our children will discover new ways how the tomorrow will be functioning.
+
+Do not teach children programming. Teach them that they can and should change their present - that is going to be our future.
+
+*By {{page.authorName}}*

articles/never-forget.md

@@ -0,0 +1,21 @@
+---
+authorName: Igor Spasić
+authorGithubUsername: igr
+issue: 118
+title: Never forget
+---
+# {{page.title}}
+
+We code software. Every day, every hour; an endless stream of code gets written and merged into the products. The human's codebase is _massive_. Space Shuttle is working with 400K lines of codes. Large Hadron Collider takes 50 million lines. And all Google services combined work on 2 billion code lines.
+
+The software runs technology. Tech becomes omnipresent in our lives; from pocket devices to augmented reality and the intelligence. The impact that technology is making on human lives is undeniable and inevitable. This fact has its burden: is the technology growing in the right direction?
+
+The answer to that question echoes from the past: it can be found in the thoughts of the first computer engineers and among the ides of the first technology visionaries. They all state the very same message: the purpose of technology is not about having everyone interacting online all the time; tech is not a ubiquitous substitution-pill (hard) to swallow.
+
+Technology is the _challenge_ for humankind to evolve. It's an opportunity to dramatically increase the collective knowledge to address the most challenging problems. It is a call to action for public and private sectors to recognize the exponential growth of humankind's challenges, and to provide the vigorous, proactive, strategic pursuit of meaningful evolution.
+
+We, the developers, are makers, creators. We are given the tools and the power of producing the code that will shape the future. We must come with disruptive ideas that will lead to organizational and societal transformations. Such attitude should be part of the DNA of any software company; that shapes the products, services and the work. We are here not to code, but to answer the challenges.
+
+Hello world, never forget to keep evolving.
+
+*By {{page.authorName}}*

articles/optimization-and-realisation.md

@@ -0,0 +1,21 @@
+---
+authorName: Igor Spasić
+authorGithubUsername: igr
+issue: 105
+title: Optimization and Realization
+---
+# {{page.title}}
+
+There is no developer that haven't heard the famous Donald Knuth's saying: "Premature optimization is the root of all evil." Often this sentence is understood in the context of the performance: speed of the software execution. However, it talks more about something else instead.
+
+It's about _the value_ that some code brings into the product.
+
+During the development, the programmer's goal is to write the code that effectively meets the required functionality. However, often from the good intentions to write the quality code, a programmer goes too far and introduces complexity that is greater than its real worth (over-engineering). In the other words, the value of the code decreases because of the unnecessary complexity increases. Similarly, sometimes the development focuses on the features that are not critical and do not give the essential value to the product. Instead, development tackles less-relevant features.
+
+In this context, premature optimization is all the work that was not spent on the production of the real value. The opposition of the optimization is _realization_: a work that actually brings the value. Now the Knuth's sentence is more meaningful.
+
+Balancing between optimization or realization is not reserved only for planning and top-level architecture. It make sense to put the work on every-day code in this perspective. No matter it is a feature or a code block, try to determine if it is an optimization or realization. If it is an optimization, figure if it is premature or not. Are you working on something that brings none or little value at the moment? Are you introducing the unnecessary complexity? Are you adding more edge cases than actually needed?
+
+The virtue is to avoid the complexity, Detect it on time by thinking about the premature optimization.
+
+*By {{page.authorName}}*