The impetus for this rambling is that there are expectations that each group places upon everyone regardless of group. For the Java/C# crowd, as an example, there is an expectation of certain protocols and mannerisms of doing things such as the use of SOAP and XML for webservices or the Python/Ruby/Node.js equivalent crowd touting heavy use of JSON and ReST based systems.
What amazes me is that the more closed in a group, the greater the expectation that the world does everything the same way seems to grow, not shrink. Note that this doesn't imply everyone, just a surprisingly larger number than anticipated (by a long shot). I don't mean to imply this is across the board with no exceptions. People used to working with web services in Java utilizing SOAP and XML seemingly care little (and know less of) the more current alternatives such as JSON and the various frameworks and standards. This is a problem because it leads to an adversarial misunderstanding which I think holds back collaborative situations as well as opportunities to expose individuals into a more cross environment manner of function.
I know that with my near-two decades of professional experience that I have worked in a core of languages (Perl, PHP, Python, Javascript, Ruby, ARexx, Pascal, etc.) with a series of acronym based technologies and formats (JSON, XML, PostScript, YAML, etc.) but that there are people out there flabbergasted to find that I've never had to work with CORBA, SOAP, XSLT, COM or even something as innocuous as certain frameworks whether Cake, Struts, Catalyst, .Net or Seaside.
The reaction is often one of shock and confusion because for so many, the entire world revolves around a solid set of standards, practices, protocols and languages which without, so many would feel like a fish out of water. In reality there are only so many ways to write an 'If loop', or an iteration over objects in an array/list/hash/tuple/set, etc. There are only so many ways to re-implement MVC frameworks or 3rd party libraries.
I often make it a practice to keep current with the langauges, frameworks and protcols of my not-so-close (codebase wise) friends so my familiarity is there, and has actually benefitted me during technical interviews over the years. This ties into what I'm saying, I will come back off of this slight detour. I was at an interview for a perl position at a large development company in the King of Prussia, PA area back in the early 2000's and it involved a 6 hour interview process on-site. I will spare most of those hours but there were two 45-60 minute interviews that stood out. The first was on 'C' followed by 'Java', neither of which I've coded professionally (or personally for any non-learning period of time). Keeping current did help me muster my way through the concepts and what not, albeit barely.
This is where I bring it back to my original point for this post. A couple of years later down the road during a technical interview for a job in a language/environment which does not have the concept of 'interfaces' (as in the C#/Java sense (to name a couple)), I was asked such a question. I first pointed out that interfaces don't exist in the target environment as it does in C#/Java, and then proceeded to give a crude explanation on how those are used in Java. The sound on the other end of the interview table was subtle but noticeable; One of confusion as to how someone doesn't use such constructs (or the fact that not all languages/platforms uniformly implement the same exact concepts).
It really comes down to education, in both directions (and I'm not implying academia to be clear). Engineers should be able to keep their familiarity with other languages/platforms current enough to be able to understand those difference between both their local toolsets and those of everyone else (to a reasonable degree). Just because I don't code in Scala professionally doesn't mean that I shouldn't read articles about Scala's 'traits', or that I should ignore a different write-up on Groovy on Grails despite not using Groovy or Grails.
This also means that those engineers of the Microsoft stack should at least familiarise themselves with what Django is, a bit of Rails, maybe some PHP and Perl, a little bit of Lua and Lisp/Clojure/Scheme, etc. In a former situation I ended up taking the development lead in a Microsoft heavy envioronment writing Classic ASP for the first (and preferably last) time, so I've practiced that which I preach. Knowing some of the pieces that differentiate the languages also give insight into work and processes that may be missing from our own stack(s). Our corpus of knowledge collectively shouldn't have such extreme gaps from discipline to discipline because it as a whole divides us from possibly creating the next big thing as well as (maybe more importantly so) fulfilling our individual potentials as developers/engineers/creators.
So take this as an opportunity to visit that neighboring x/y/z technology users group, maybe even a smaller convention/conference to get uncomfortable yet ultimately expand one's own horizon and knowledge-base. Only good things can come of this. Continuous improvement doesn't solely refer to processes and applications but people as well.
This is where I bring it back to my original point for this post. A couple of years later down the road during a technical interview for a job in a language/environment which does not have the concept of 'interfaces' (as in the C#/Java sense (to name a couple)), I was asked such a question. I first pointed out that interfaces don't exist in the target environment as it does in C#/Java, and then proceeded to give a crude explanation on how those are used in Java. The sound on the other end of the interview table was subtle but noticeable; One of confusion as to how someone doesn't use such constructs (or the fact that not all languages/platforms uniformly implement the same exact concepts).
It really comes down to education, in both directions (and I'm not implying academia to be clear). Engineers should be able to keep their familiarity with other languages/platforms current enough to be able to understand those difference between both their local toolsets and those of everyone else (to a reasonable degree). Just because I don't code in Scala professionally doesn't mean that I shouldn't read articles about Scala's 'traits', or that I should ignore a different write-up on Groovy on Grails despite not using Groovy or Grails.
This also means that those engineers of the Microsoft stack should at least familiarise themselves with what Django is, a bit of Rails, maybe some PHP and Perl, a little bit of Lua and Lisp/Clojure/Scheme, etc. In a former situation I ended up taking the development lead in a Microsoft heavy envioronment writing Classic ASP for the first (and preferably last) time, so I've practiced that which I preach. Knowing some of the pieces that differentiate the languages also give insight into work and processes that may be missing from our own stack(s). Our corpus of knowledge collectively shouldn't have such extreme gaps from discipline to discipline because it as a whole divides us from possibly creating the next big thing as well as (maybe more importantly so) fulfilling our individual potentials as developers/engineers/creators.
So take this as an opportunity to visit that neighboring x/y/z technology users group, maybe even a smaller convention/conference to get uncomfortable yet ultimately expand one's own horizon and knowledge-base. Only good things can come of this. Continuous improvement doesn't solely refer to processes and applications but people as well.
