| It seems that folks here are reacting to the angst of the author as well as the literal meaning of the language used to make his point instead of contemplating what the author is trying to actually say. Otherwise, why get hung up on definitions of "coding" vs "programming" or concepts such as "text" vs "visual"? I think this post is an expression of the frustration that we have all reached at some point (if not many points) along the way while using any language or solution or architecture: this sucks and there's got to be a better way to get shit done! How many times have you been working on project "foo", ran into a problem and employed solution "bar" (or better yet, created solution "baz" on your own) in order to solve your problem...only to find yourself derailed into a swamp of limitations with "bar" (that everyone forgot to mention in that awesome blog post you found)? Or, how many times have you lied to yourself and said "I'll improve upon the limitations of 'baz' in the v2 release" of your home grown masterpiece only to never return because you're actual goal is to finish the "foo" project? The problem might be the tools or the user or the application or even the philosophy...or it might be a combination of that list plus some I haven't mentioned. Perhaps these problems have already been solved and the lessons have been lost? Or, perhaps more analysis is needed to come up with a new way around this issue entirely? I certainly don't have the answer right now but this article made me take a step backward to survey the landscape (or the wake?) of the most recent 10 years of "disruptive" (read, self-serving) technology and I feel an undeniable sense of dissatisfaction with it all. Maybe that desire for something better just means I'm a programmer and not a coder? I don't know but I won't avert my eyes from the problem no matter how obvious it is to everyone simply criticizing the article. Awareness is the first step to understanding the problem you are trying to solve and I see people recoiling from that. Denial is a sign that a belief (or end of thought) is overruling the critical thinking process and to me that's acceptance of the status quo (not just dangerous but stupid too). I did get a good chuckle at the metaphor provided by xerophtye's comment "you think of a pretty picture and tada! It appears on canvas!" The truth is always funny so perhaps this comment encompasses the entire article but I think it oversimplifies what the article attempts to drive toward. Sure, comprehension of the building blocks (or, the colors) allows you to build bigger and better buildings (or paintings), but, if that were truly the case, why aren't things improving? Wouldn't all of the so called experts chiming in have already built bigger and better buildings? And if so, what are they? NoSQL? Twitter Bootstrap? Ember or AngularJS? Bitcoins? Animated CSS? All I see are copies of the original idea done "my way" which is "better". Amateurs borrow, professionals steal. And that is the process improvement methodology I see employed today. If everyone thinks they know their craft so well, inside and out (and, for safety, let's say I don't), how might you take that knowledge (and a step back) and change/improve upon how things are accomplished today? I think that's the core of this article. To put it another way, if the acquired knowledge to accomplish tasks via "programming" is only useful and self-serving within the realm of the library/language being used, how is that moving the entire ball forward? I think the solution implied here is that a re-examination of history and more experimentation with different architectures or applications of the existing building blocks might get us over this hump we're facing. |