abundance part 2, generalism

I pondered about the abundance of Javascript libraries, about it being both good and bad. While I still think it’s both, I tend to think the negative aspects emerge from our established ways of viewing prowess in technology.

What I see as a problem is this notion that one should be proficient at some certain library or framework. Instead, I think we should be good developers in general, and be able to learn and adopt new stuff rather quickly. We should be open minded in trying out new stuff without fearing too much about the time used (and potentially wasted) learning.

expertise #

Investing in one specific library might be daunting. A well versed generalist can learn (almost) anything in a relatively short amount of time. All of us developers know this. What’s disturbing are those old-fashioned requirements for job or project positions, that list a bunch of technologies an applicant should be proficient with. Most of the time, they are too specific and require a ridiculous amount of experience with a library, basically asking for devotion to it from the applicant.

The best examples are them wanted ads with years of requirements of something that hasn’t even existed for that long. Technological adoption and spread might be so fast, that even if the ads are written by technologically aware people, they still have no idea what they’re asking for.

And as we know, using one single set of technologies for years and years is risky, and the opposite of awareness. We end up solving all our problems with the tools we are accustomed with. I think I’ve never seen a job position for “a person with all kinds of experience and some of it with weird arcane shit”. These positions and interviews do exist, and companies actually look for these kind of developers.

The problem is, most think we have to have experience in something specific, before being able to partake in anything where they are used in. What’s really important, is the awareness of these new and different approaches, of knowing the unknown.

options #

libraries, in general, abstract functions and operations, so that we don’t need to implement those ourselves. What can happen, is that the abstraction becomes blurred with the reality, and we no longer understand what happens at framework, library, language or system level. This happens easiest when only a few libraries are used, and the user doesn’t bother to learn the basics. This is fine at first, as one has to start somewhere. But in the long run, dipping into different implementations forces us to understand the basics, instead of doing something “the x way”.

With knowledge of different approaches, we have the ability to choose the currently most fitting one. More libraries mean more options. More options mean less dead-ends.

I believe the more we learn different stuff, the easier and faster the learning gets. Breaking off from the usual and mundane helps with detecting new ways of thinking.

 
0
Kudos
 
0
Kudos

Now read this

golang and positive constraints

I wrote a smallish program in Go around a year ago. Today, a colleague shared this article, and inspired by it, I went back and had a look at my now old project. The simplicity of it was surprising. an argument for any language # One can... Continue →