Tag: ffs

I saw a quote today somewhere that I didn’t save and don’t properly recall along the lines of most people don’t know what it’s like to be in the privileged position of a programmer who is able to code your own custom apps.

Slightly earlier, I’d idly wondered about the rhetoric of “everyone must learn to programme”, and how many people I know found it useful in their work to “do some programming” yesterday, or last week or over the last month.

I also wonder about how many of the folk preaching “everyone should learn to programme”:

a) actually know how to write code (and if they don’t, do they intend to learn? When?);
b) ever use code to do anything (i.e. why should folk learn to code? What’s it useful for?)

Whatever…

Going back to the privilege thing, what I think folk don’t realise is how little you need to do to get things done, if you know what to do – or look for.

One of the reasons I like the RStudio and Jupyter notebook environments, particularly for visualising data, is that if you have the data looking right, (i.e. when you display it as a table, it has things arranged in the right way in a table made up of  rows and columns) you can create all manner of wonderful, interactive graphical outputs with a single line of code. Other folk have written templates from creating embeddable interactive HTML widgets, and transforming the data in my data table into the data the widget needs to display the chart.

In itself, code can often be just a written version of a menu option you might select or a set a values you have selected in an interactive form. Nothing new, just turning point-and-click choices into word equivalents and then writing them down, so the machine can do whatever it is rather than you.

Things are also – arguably – getting easier.

For example, over the last week Simon Willison has been tinkering with a really useful set of components for querying data. This started with a tool to put CSV files into a simple database without the user having to do anything other than say – put these files into a database. And then a tool that let you publish the database as a service, either on your own computer or the cloud (again with a single line) so you could query it through a browser. Now there’s a UI, and a simple tutorial for building a simple app to search for trees in San Francisco. (Writing the HTML might be tricky, but that page could be based on a template? Or the app could perhaps be accessed via Jupyter notebook using dynamically created ipywidgets and published using appmode.)

Taken together, with a few lines of code, you can create and publish your own interactive data explorer , along with an API you can access from elsewhere.

Perhaps that is a privilege only “coders” can avail themselves of. But why?

With knowledge of a few small tools, the sorts of thing they do (rather than how they do it), and how to wire them together, you can start to create powerful, and useful, applications.

Which makes me wonder again about whether it is really so much harder to teach programming stuff to adult novices using real tools to solve real problems compared to teaching them how to use Scratch to make an animated owl blink its eyes or make a turtle draw a square?

Pedagogy is an oft used word in the OU, which in derivation means “lead a child”. (The adult equivalent, andragogy, is rarely used, self-directed heutagogy even less so.) Can we really do no better at teaching adults programming and what it might be used for than starting them off with months of programming using tools developed for teaching primary school children, some of which was invented getting on for fifty years ago? Are we really that stuck for coming up with teaching ideas that not only teach principles of “computational thinking” and core programming ideas, but also help learners see how they might be able to use the ideas in practice and perhaps even set them up with a chance of using them for real outside of their studies? (SMEs employing three people probably don’t need a full time developer, but if one of them can hack a solution to problem that solves a need, or makes a particular task slightly easier, it doesn’t really matter?)

Or perhaps the practical uses get in the way of teaching the “pure*, abstract coding principles?

I JUST DON’T UNDERSTAND WHAT WE’RE TRYING TO DO?!

In that oft referred to work on innovation, The Innovator’s Dilemma, Clayton Christensen suggested that old guard companies struggle to innovate internally because of the value networks they have built up around their current business models. Upstart companies compete around the edges, providing cheaper but lower quality alternative offerings that allow the old guard to retreat to the higher value, higher quality products. As the upstarts improve their offerings, they grow market share and start to compete for the higher value customers. The upstarts also develop their own value networks which may be better adapted to an emerging new economy than the old guard’s network.

I don’t know if this model is still in favour, or whether it has been debunked by a more recent business author with an alternative story to sell, but in its original form it was a compelling tale, easily co-opted and reused, as I have done here. I imagine over the years, the model has evolved and become more refined, perhaps offering ever more upmarket consultancy opportunities to Christensen and his acolytes.

The theory was also one of the things I grasped at this evening to try to help get my head round why the great opportunities for creative play around the technologies being developed by companies such as Google, Amazon and Yahoo five or so years ago don’t seem to be there any more. (See for example this post mourning the loss of a playful web.)

The following screenshots – taken from Data Scraping Wikipedia with Google Spreadsheets – show how the original version of Google spreadsheets used to allow you to generate different file output formats, with their own URL, from a particular sheet in a Google spreadsheet:

In the new Google spreadsheets, this is what you’re now offered from the Publish to Web options:

[A glimmer of hope – there’s still a route to CSV URLs in the new Google spreadsheets. But the big question is – will the Google Query language still work with the new Google spreadsheets?]

embed changes everything

(For some reason, WordPress won’t let me put angle brackets round that phrase. #ffs)

That’s what I said in this video put together for a presentation to a bunch of publishers visiting the OU Library at an event I couldn’t be at in person (back when I used to be invited to give presentations at events…)

I saw embed as a way that the publishers could retain control over content whilst still allowing people to access the content, and make it accessible, in ways that the publishers wouldn’t have thought of.

Where content could be syndicated but remain under control of the publisher, the idea was that new value networks could spring up around legacy content, and the publishers could then find a way to take a cut. (Publishers don’t see it that way of course – they want it all. However big the pie, they want all of it. If someone else finds a way to make the pie bigger, that’s not interesting. My pie. All mine. My value network, not yours, even if yours feeds mine. Because it’s mine. All mine.)

I used to build things around Amazon’s API, and Yahoo’s APIs, and Google APIs, and Twitter’s API. As those companies innovated, they built bare bones services that they let others play with. Against the established value network order of SOAP and enterprise service models let the RESTful upstarts play with their toys. And the upstarts let us play with their toys. And we did, because they were easy to play with.

But they’re not anymore. The upstarts started to build up their services, improve them, entrench them. And now they’re not something you can play with. The toys became enterprise warez and now you need professional tools to play with them. I used to hack around URLs and play with the result using a few lines of Javascript. Now I need credentials and heavyweight libraries, programming frameworks and tooling.

Christensen saw how the old guard, with their entrenched value networks couldn’t compete. The upstarts had value networks with playful edges and low hanging technological fruit we could pick up and play with. The old guard entrenched upwards, the upstarts upped their technology too, their value networks started to get real monetary value baked in, grown up services, ffs stop playing with our edges and bending our branches looking for low hanging fruit, because there isn’t any more. Go away and play somewhere else.

Go away and play somewhere else.

Go somewhere else.

Lock (y)our content in, Google, lock it in. Go play with yourself. Your social network sucked and your search is getting ropey. You want to lock up content, well so does every other content generating site, which means you’re all gonna be faced with the problem of ranking content that all intranets face. And their searches universally suck.

The innovator’s dilemma presented incumbents with the problem of how to generate new products and business models that might threaten their current ones. The upstarts started scruffy and let people play alongside, let people innovate along with them. The upstarts moved upwards and locked out the innovation networks around them. Innovations end. Innovation’s end. Innovation send. Away.

< embed > changes everything. Only this time it’s gone the wrong way. I saw embed as a way for us to get their closed content. Now Google’s gone the other way – open data has become an embedded package.

“God help us.” Withnail.

PS Google – why did my, sorry, your Chrome browser ask for my contacts today? Why? #ffs, why?