Is There Tech Knowledge We Should All Have?
For a few years at least I have noticed the strong leaning towards choosing to build technology tools with "declarative" functionality, as opposed to introducing functionality that is mostly made out of "code". Of course, this is something of a paradox, given that the "declarative" functionality - also well-known as "drag-and-drop" or "clicks-not-code" functionality - is built entirely on top of, you guessed it, code. Something has to tell the computer to let you to drag and drop something somewhere and have it work the way you expect it to work, and do the thing you expect it to do.
Regardless of the paradox, I think the focus on declarative approaches has been a great advantage to us all. There are so many more freedoms to be had from having access to functionality that allows you to do so many of the customizations, automated processes, and inspired innovations that might previously only have been available to professional programmers (aka developers). However, the pace of technology is hyperspeed, and in just a short time I've begun to question exactly how heavily we should be leaning into "clicks-not-code" as a mantra, particularly in the non-profit world.
Even when I am working in a system as foundational as a Spreadsheet, I'm seeing many examples of where declarative functionality hits its limits, and the processes and needs of the non-profit actually do benefit from more technical complexity, which can be delivered through code in Macros (in Excel) or Google Scripts (in Google Sheets). I believe this is truly a testament to the sometimes daunting missions that non-profits are serving, the complexity of human-centered social justice work, and the tenacity of mission-driven people who, when given the chance to dream big about their technology, will almost always come up with big dreams that go beyond the "out of the box" functionality.
I'm not necessarily advocating that all non-profits need to have people on staff who are programmers, or that they need to use outside consultants to build them customized tools and maintain those tools (although I do recommend having dedicated technology roles at organizations, advocated for none better than by the folx at The Build Tank. I have been re-thinking the "baseline" knowledge that all non-profit organizations need to have on staff. For a long time, I've advocated that spreadsheet skills are the essential baseline for everyone in mission-driven work. Basically everyone uses them in one form or another, and they are an essential part of any good technology ecosystem. But I have been noticing recently that even the smallest spreadsheet projects I work on within organizations are really stepping stones to those bigger and more complex dreams of using our technology to help us serve our missions. It might be time for our "baseline" of tech knowledge to go beyond spreadsheets and data models, and to include at least some programming knowledge as well.
Again, I'm not saying we all need to learn to code. We absolutely need to keep using declarative approaches (I love them, I do!). I am saying that we may want to add some basic knowledge about programming into what we think of as "essential" for basically everyone in our organizations to have (and therefore imperative for the organizations to support professional development in these areas). What does “baseline” coding knowledge mean and look like? This is subjective and contextual - there is no single answer to what this will look like. I would suggest that we start with the big picture concepts before trying to learn any technical skills. I have been considering this for a while, and just today I learned a fun concept as part of the Java (programming language) course I’m taking thru CodeAcademy (trying to follow my own advice and step up my own technology knowledge). It is the concept of procedural abstraction.
Procedural Abstraction
Definition #1: Procedural abstraction is when we know what a method or procedure does, or what we want it to do, but we do not know how it does it. (source)
Definition #2: A process of focusing attention on the main problems by ignoring lower-level details…It’s a model of what we want a subprogram to do (but not how to do it). (source)
Definition #3: We say precisely what we want a procedure to do in terms of its arguments, and expect it to do just that, nothing more and nothing less. Then we need have no knowledge of what is inside the procedure to make successful use of it. (source)
So basically what I got from these descriptions was exactly the same idea about “declarative” functionality - we can “drag-and-drop” things or create pivottables, but we really do not know or understand how the mechanisms and code behind these functions is written and working. The best that we can do is try to align our expectations with that of the code or the user interface, and try to work toward those shared expectations. You expect that it will work, but not how it works.
We can bring this concept out of the actual code being written to look at how we think about our "baseline" knowledge about coding for people in mission-driven organizations. We should have a sense of what can be done, even if we don't know how it can be done. Here are some cool things my team has done recently with code that may serve as some inspiration for you to think through what else you might want from your data systems:
Give a little more flexibility to your website/software: Not all code is about “software programming” - code that helps manage the design and aesthetic of a website or a piece of software can come in handy A LOT. The coding languages used in this type of work are most typically HTML and CSS. My website is built on Squarespace, which has some awesome drag-and-drop functionality. But I didn’t like being boxed in by the sections that you can get from just clicking. I knew that HTML could help with this, but not necessarily how. After much Googling and trial-and-error, I was able to increase the size of those sections that I felt trapped inside - much less claustrophobic now because of code. I’ve also used HTML and CSS to make changes to how actual software looks - most specifically the LMS Canvas, which, like many systems, allows you to use your own HTML and CSS code to impact the look and feel of the system.
Replace manual, repetitive tasks: There are also a lot of declarative options for replacing manual, repetitive tasks. Formulas in Google Sheets can eliminate nearly all forms of “copy-and-paste” happening out there in the world, not to mention streamlining formatting with Conditional Formatting rules. Systems like Salesforce, Zoho, Trello, SurveyGizmo, and many many more have some form of “automation” services within their own platform. That means a “declarative” or drag-and-drop or rule-making functionality that allows you to do a range of things, from simple “If this, then that” automations all the way to complex business processes that can be built on a set of rules and repeatable steps and pathways. For example, a client of ours has a complex and specific way of creating reports in Google Sheets each week of new and updated information about job candidates. Not only is the information being updated weekly, but the way that we want the spreadsheet to actually look can be different each week based on the data (ie. we only show jobs in our spreadsheet that have active candidates in them. We have different sections on a sheet for each job, so if the last applicant for a job exits the conversation, we don’t want to see that section for that job anymore). Some of this we were able to achieve with some smart data organization and spreadsheet formulas, but we also used Google Scripts to write code that would help us out by doing some of those formatting updates, which are based on rules. And the code is schedule to be run each night, so that smart reformatting happens overnight while we sleep. No more copy-and paste!!
Taking a snapshot of spreadsheet data: Formulas are an excellent thing in Spreadsheets. They are like the “methods” or “subprogram” or “procedures” from the definitions of Procedural Abstraction above. This is because each of these things is set up to take in information and do some calculations or actions based on that new info. For example, I have a dashboard built in Google Sheets, and the data for that dashboard comes from a time-tracking system. We download a report from the time-tracking system each week, copy-and-paste the data into the spreadsheet, and then watch the formulas update on their own. However, we needed a way to take a “snapshot” each month, ones that would never be updated, even if new data came in. We created some code in Google Script that was able to handle this! It uses a “button” (thank you to whoever at Google spent time on making buttons in Google Sheets partially declarative!), which is really just an inserted drawing from Google Sheets, but a drawing that can be “linked” to a script. When someone clicks on the button, several things happen: a tab is duplicated and named for a calendar month based on cell values on the sheet, all the formulas on that page are removed and just the text or numbers of the answers remains, the drawing that got copied onto this new tab is removed, and a few more formatting changes later, and we’ve got a snapshot in a new tab that won’t update when the formulas on the original tab update with new data.
Get your data out of your systems the way you need it: There are oh so many reasons why you will need to get data out of your systems that hold it. Some systems have less-than sophisticated reporting capabilities, and you may not even be able to get ALL of your data out of your systems. Sounds crazy, but I’ve seen it with my own eyes. But now many many tech systems are developing their APIs (code that allows you to “talk” to your tech system in several ways, but most foundational to get data out of the system and into your hands. In fact, the name of the kind of API that we use most frequently is named a “GET” API call). There are some very nice declarative systems that can help you with using APIs (Zapier, Google API Connector). And if you really want to be fancy, you can add a programming language into the mix and write code that will get your data and let you decide how that data will be received, organized, and formatted.
As we consider our resources and investments in data & technology for our mission-driven organizations, we should think about the “baseline” knowledge that we want everyone in our organization to be able to have and be supported in learning. Spreadsheets aren’t going anywhere, and they are such a great introduction to some core data & technology concepts. Most mission-driven organizations use some sort of relational database like a CRM or a Donor database, so we need to know about data models. And for coding, we need at least an understanding of how code might be able to customize our systems or replace repetitive tasks, and how to consider the costs and benefits of pursuing “code” solutions. Plus, wouldn’t it be nice to know a little bit more about how this miraculous computer-box in front of us works? I personally like to feel more in control of my digital experience - I want the computer to be working for me, not the other way around - and as they say, knowledge is power.
What projects have you worked on where a bit more knowledge about programming may have come in handy for thinking through and delivering solutions? Have you made any cool Google Scripts? What did they do, and why? Have you been burned by code and want everything to be declarative? Share your thoughts and experiences!
