[HN Gopher] The Myth of Architect as Chess Master
       ___________________________________________________________________
        
       The Myth of Architect as Chess Master
        
       Author : yarapavan
       Score  : 11 points
       Date   : 2020-02-17 15:08 UTC (7 hours ago)
        
 (HTM) web link (www.bennorthrop.com)
 (TXT) w3m dump (www.bennorthrop.com)
        
       | loopz wrote:
       | Architects have two primary purposes (not roles):
       | 
       | 1) Facilitate that architecture and design happens in teams (dev
       | or not)
       | 
       | 2) Ensure coherency of architecture
       | 
       | That's it folks!
        
       | cmhnn wrote:
       | If the argument the blog is trying to make is Architects can't
       | know everything then it's a bad article to submit.
       | 
       | On the other hand, if the argument is a boss should not expect
       | someone called Architect or senior engineer etc. to be able to
       | troubleshoot based on experience I have a problem with that.
       | 
       | If someone can't be air dropped and they have a title that is
       | intended by the business as code for _a senior level software
       | person who can think of how to build systems and can also build
       | them themselves_ , then I am not sure what they bring to the
       | table.
        
         | loopz wrote:
         | This is the problem with development for, forever. Most of the
         | time, people are tasked with: Here's the spec/user story/loose
         | idea/unrealistic wishlist, and can you be done before this
         | weekend at least?
         | 
         | What's the problem again? The facilitation of foundational
         | discussions and exploration is seen as waste. So the business
         | spends X months building the wrong idea, without any feedback
         | and adjustments along the way whatsoever instead.
         | 
         | To air-drop someone senior to set things straight. What a great
         | way to sabotage organisational learning and simplification. Not
         | that anybody gives a rats ass about eachother anyways, right?
        
       | rehasu wrote:
       | And then you go another level deeper and see everything is
       | actually just different ways of doing the same old Linux and/or
       | Java. I feel especially in Ops people can see that all the time.
       | For instance just today I saw someone debug a NO_PROXY topic in
       | Kubernetes. Kubernetes is super cool and works different than the
       | old LAMP stacks or even Openstack. But still they deal with
       | NO_PROXY not being standardized problems. Also shows that the
       | same, actually hard problems (like standardizing something that
       | is "out there" for more than a decade already) are never really
       | solved. Each shiny new tool comes with its own way of doing
       | things, but what they do with your input is in the end always the
       | same. Mounting, multiprocessing, sockets, string parsing, memory
       | management, log searching, etc.
       | 
       | So yes, I think there's a way to become a chess master. You just
       | need to go one level deeper and accept that there might be
       | multiple topics that each will need half a decade to learn good
       | enough to be useful.
        
       ___________________________________________________________________
       (page generated 2020-02-17 23:00 UTC)