I was on the Phone with Doc Norton a couple weeks ago which resulted in a truly thought provoking experience.
Doc told me that in the past, some companies would post a job requiring a programming language that had not yet been adopted by mainstream programmers. Hence, these companies would seek talented and motivated developers by requesting a unique language that only this breed of developer would have experience using. Specifically, this obscure language would usually be harnessed by developers who write code on their personal time. Hence, this strategy would identify highly motivated developers.
Doc then provided me with an example of companies that would seek out Ruby developers. Again, the client would feel confident that they were hiring highly motivated, multi-paradigm developers. Thus, these companies benefited greatly by applying this filter for hiring this breed of developer. Then something happened.
Doc told me that businesses were benefitting greatly by hiring mystical Ruby developers. That is until the “Ruby on Rails” framework was released. Thus, this framework significantly reduced the development effort required for Ruby developers to pump out applications. However, the side-effect of this was that many DMDs (i.e. Dark Matter Developers) entered the arena of Ruby programming and thus had a heavy reliance on the “Ruby on Rails” framework to solve their problems without having a deep understanding of Ruby language fundamentals. Thus, these companies now had to once again develop a strategy to filter top-notch talent from the rest of mainstream programmers.
Once again, Doc had inspired me. I immediately reflected on my own dependencies for some frameworks. In my case though, I tend to use the frameworks that I write myself. However, I have experienced shops that blindly mandate the utilization of specific frameworks without identifying the root cause for having to use these frameworks. Based on my reflection on the shops that mandated the use of specific frameworks without any rationale, I realized that frameworks today are typically used as a prescription medication. Hence, these frameworks treat the symptoms of a problem. However, as professional developers, we shouldn’t treat symptoms and send the client or the app on their way. No! As professional developers we should stop looking for a prescription and instead diagnose the true source of the problem. Is this an application problem or is this a people problem? Almost always, the problem is a lack of understanding…