We are the Borg

We are the Borg. Lower your shields and surrender your ships. We will add your biological and technological distinctiveness to our own. Your culture will adapt to service us. Resistance is futile

• The Borg, Star Trek: First Contact

To those not familiar with the above quote, The Borg are a (hopefully) fictitious hive mind collective from the world of Star Trek: The Next Generation. Their key characteristics include:

• Converting other life forms to Borg-controlled cyborgs via nanites
• Integrating the technologies of other cultures into the collective
• Adapting to new threats by rapidly adjusting technology

Recently, I've been thinking more about our programming languages and even us as engineers as not too dissimilar to The Borg.

Let me explain.

---

Language Evolution

I'm going to use .NET and JavaScript as examples here, if only because I've been working with them the longest, but also because they've been around awhile and are still relevant and still adapting.

Example .NET Framework

I've been working with .NET since it was in Beta 2 back in 2001. A platform doesn't last for nearly 20 without making some adjustments.

.NET is a beast that is hyper-aware of its context in the world, hence the movement away from being tied to Windows and towards cross-platform support. I've seen the rise of generics, extension methods, LINQ, Entity Framework, .NET Core, cross-platform support, WPF, Silverlight, Blazor, Windows Phone, Universal Windows Platform, WCF, Workflow Foundation, Razer, ML.NET, Azure Functions, JSON serialization, Document Databases, and so many other technologies.

Perhaps most notably, with the recent increase in popularity of Functional Programming, .NET has introduced the F# programming language, a functional programming language that is completely compatible with the .NET Framework. Additionally, C# and F# libraries can communicate with one another, making it possible to integrate F# into existing projects.

This ability to evolve over time and add and drop features and tools over time has made .NET an incredibly capable platform to develop with and one that continues to provide more opportunities to learn and grow over time.

Example: JavaScript

When I first came into programming, JavaScript was this small thing you used for form validation and not much else. It was difficult to work with, tended to be neglected, and was not a first class citizen within the programming world.

Now, JavaScript is so incredibly powerful that it not only runs complex single page applications (SPAs) via frameworks like Angular, React, and Vue, but it also runs server-side code as well via frameworks like Node.js. Additionally, with MongoDB and similar technologies, JavaScript is the native language of some database providers, making it a truly full-stack language.

What changed? The language evolved over time. With EcmaScript, JavaScript gained some powerful object-oriented features. With technologies like TypeScript and CoffeeScript, we gained static type checking in a dynamic language and code that transpiles down to JavaScript, removing some of the quality dangers inherent in a dynamic language.

Additionally, more and more people have made JavaScript their language of choice, with package managers like npm and Yarn providing ways of easily integrating external code into your applications. With libraries like JQuery and Lodash, the language gained some very well-defined productivity improvements. With CSS frameworks like Bootstrap and Material Design, JavaScript got some key partners in developing web applications.

Developers

It doesn't stop at our languages, we as technologists evolve over time, gaining a wider breadth of experience and growing deep specializations in key languages and aspects of frameworks.

When I became a manager, I realized that I myself was a collection of my personality and habits mixed with every way I'd seen my prior managers succeed and fail - vowing to emulate their successes and work to find mistakes of my own to make instead of repeating their own.

In fact, as technologists, with techniques like Test Driven Development, we aim to inoculate ourselves against bugs so that the same bug never recurs. On a higher level, developers often try to avoid making similar types of mistakes.

Making Defects Impossible

Matt Eland ・ Aug 31 '19

#testing #dotnet #javascript #codequality

Summary

This Borg-dom of ours is not a bad thing (other than maybe not the best thing to bring up on a first date). This is a part of who we are and what makes us high quality engineers with a large array of increasingly improving tools and languages.

Keep evolving. Keep assimilating new technologies, concepts, and ideas.

Live long and prosper. We are the Borg.

Comments

[Avalander]

That was a fun read and an odd simile, thank you!

[Matt Eland]

Thanks for the comment. It was fun to write. That's been rattling around in my head for a bit now.

---

Ha ha! Absolutely a simile.

In no way was I suggesting we actively co-opt and absorb humanity into our hive mind. Any allegations as to that sort of behavior would be promptly denied and any relevant evidence hidden.

Resistance is futile.

[Nucu Labs]

When I first read the title I was thinking of the borg pattern in Python

[Matt Eland]

Tell me about that. I'm not familiar with it.

[Nucu Labs]

class Borg:
    __shared_state = {}
    def __init__(self):
        self.__dict__ = self.__shared_state

In Python you can override the built-in __dict__ attribute with your own dictionary. The __dict__ holds all the attributes of the Borg class and __shared_state is a static variable. When instantiating a Borg class __init__ is called and it overrides the __dict__ with the static __shared_state, thus each class will have the same brain: __shared_state. If you modify variables, their values will be reflected in __shared_state. :D