Decol Futures: Servers, More Game Jams, and Data as Dev Work?

A newsletter to learn about practical ways to decolonize your research and data work-lives with byte-sized drabbles about the daily life of a data professional.

I almost didn’t get a second issue out this month because I competed in the Spooktober Visual Novel Jam. I coded so much, I’m still seeing dollar signs wherever I look (dollar signs are a symbol used when writing code). My demo is free to play on itchio and voting is open to the public until October 27th!

GIF of real gameplay in my story-driven psychological visual novel, Late Night Surfing.

Now on to the data lore!

Digital Asset Managers Know Back-End Dev Stuff

I see a lot of job advertisements asking for developers in asset management departments or organizations. Their description is vague and talk about “supporting tools or infrastructure,” which is then described as a SQL database or on a kind of server. Approach these descriptions cautiously.

If you’re trained/educated in development, these vague terms are a turn-off. Most tech stacks are going to be based in SQL (a kind of language) and the pay is significantly less than if you worked in a technology-specific job. So what will you actually be doing?

Digital asset managers work with a wide variety of content, but also tech stacks. Tech stacks are the pieces of your organization’s technology systems that collectively make up your digital ecosystem. Most ecosystems are made up of servers, several databases connected through APIs, and external tools, like email or Google Drive. Because digital asset managers work in the tech stack, they have backend developer skill sets.

What does DAM have to do with Servers?

Databases (in our world called content management systems) are virtual storage houses that live on physical or virtual servers. When you update a catalog record or change an item’s tags, that data is pushed through your system to the underlying database stored on the server.

What Can Digital Asset Managers Do on Servers?

Emphasis on can. It all depends on where you work, the content you’re working with/on, and how good your programming and logic skills are.

Most content management platforms (think Bynder, Adobe, Collective Access) have a GUI (graphical user interface) which is like a puppet screen for the command line and code infrastructure that makes up your database application. It’s a pretty, low-tech skill way to manage and manipulate data stored in a database.

All platforms have developer documentation that tells you what magic words to type in the command line to do the data thing you need (like reindex search or add a new search facet).

  • Sometimes you have to make big changes - like migrate data - using the command line.

  • You want to batch upload content.

  • You might have server (with no database) that’s just for storage, so you use the command line or a SFTP client to move files there.

Then What’s the Deal with Separate Jobs for DAM on a Server-Level?

Well…corporate greed! It’s also industry expectations.

Traditionally, digital asset managers evolved from librarians and archivists - historically educated without teaching computer science or data science. If you look at a DAM job posting in the corporate world, you typically don’t see requirements for knowing Python, SQL, APIs, or AWS (Amazon Web Services). From a employer perspective, those programming and computer science skills are considered “developer-only.”

Having separate jobs creates extra red-tape to cut through. To push data to a server without using the GUI, you need administrative permissions on the server. Case-in-point: You want to batch upload assets to a system called contentDM? You need a dev for that. The system only lets you batch upload via the command line.

Another issue is that most organizations don’t have in-house developer support for DAM. If there’s I.T., it’s usually for the entire organization and they provide general support (e.g. update your computer, fix printers, run chron jobs).

Let’s Create!

I’m open to collaborations, freelance gigs, and conversations about the ideas I shared. Feel free to get in touch and comment on the newsletter.

Reply

or to participate.