Bulletin 19 July 2019. AI vs Jobs, take two
Crunching in the shoes of others
I was starting to think I was becoming a bit of a one-trick pony with this bulletin. You know, a bit naive, over-optimistic, potentially ranty and vague (or in the immortal words of Neil Ward-Dutton, not very crunchy). All of these things may be the case but I recorded a podcast this week that brought it all into focus.
In case I haven’t mentioned it, I’m the lucky host of a podcast for GigaOm called Voices in DevOps. Lucky not only because it is a topic, or field, close to my heart; but also because I learn so much from the guests, each of whom’s job is to answer one simple question: what is going to make DevOps work in the enterprise?
Some guests take a view based on their own background: so, for example, I’ve discussed a product management mindset on a couple of occasions, and other times the conversation has turned to data and measurability, or collaborative best practice. Meanwhile I’ve been able to test out my own theories, for example around the Guru’s dilemma.
On a couple of occasions, such as this week, the debate has turned to how provenance influences how the situation is framed: essentially the meta-level of the above paragraph. So, for example, if you have a room full of people with a development background, they may take the view that everything can be programmed, and therefore should be.
On the first point, mathematically, they are not wrong. One of the late, great Alan Turing’s principles was that any complete formal language can be used to specify any other complete formal language (or to put it another way): in other words, you can express anything you like as a program. The second point leads to the enticing “as-code” notion, for example expressing infrastructure, security, test scripts as code.
Trouble is, just because something can be done in a certain way, that doesn’t mean it should. My guest this week (David Torgerson, of Lucid Software) warned against the danger of employing programming generalists, rather than specialists in other areas — such as, let’s say, database engineers. Yes, and indeed, you can express a database structure as code.
However, I was reminded of another conversation I had with Neil W-D, who has a knack of making things very crunchy very quickly. We were talking about the nature of programs or process steps to impact data and state, and vice versa, to the extent that the two intertwined. “What, you mean like, “is it a wave or a particle?”,” he asked. Yes, that’s precisely what I meant, if only I could have been crunchy enough.
In my experience, programmers do not always make brilliant database engineers and vice versa: actually, in my own personal experience, I’m happy to write programs but I find myself wanting to leave the room quickly if every I am faced with a spreadsheet… which, yes, makes being a research analyst a challenge sometimes. And don’t start me off about expenses.
But, to David’s point, we need people of both types, and a lot of other types to boot. Horses for courses, different problems require different brains, teams should be cross-functional not only because we need a variety of skills but because we need a variety of minds (which is also the root of my thinking about needing to pay more than lip service to ideas around diversity).
Without talking too much about the topic at hand, DevOps blessing and curse is that it has been led by developers — it is DEVops and not devOPS at its origin. Which leads to another strange notion, that operations can be automated out of existence, which is clearly an idea from somebody who has never worked in a data centre (cf yet another of these newsletters).
That’s all, really, apart from recognising our own preferred framing , and ensuring that we don’t see it as the only view. We can all benefit from walking in the shoes of others from from time to time, or risk believing that they don’t need to exist.
Smart Shift: The truth is out there
In this section we go from loyalty points to virtual cash, following the rise of Bitcoin and its supporting platform, Blockchain, and we look at its applicability to the music industry and other domains. “It’s not about the money,” says anyone who thinks it is about the money.
Thanks for reading.
