August 15, 2023
Season 1, Episode 19
In this episode, Jay Keshur interviews Charles Humble, the editor-in-chief at Cloud Solutions. Charles delves into his unique journey from an English literature background to the tech world, discussing the evolution of remote work, the challenges and benefits of cloud migration, and the intersection of technical writing in the modern cloud era.
Guest Introduction:
Charles Humble is the editor-in-chief at Cloud Solutions, a cloud-native consultancy. With a background in English literature, Charles has carved a niche for himself, blending his love for language with the intricacies of the tech world. Over the years, he has witnessed and been a part of the transformative journey of cloud computing and remote work.
In This Episode, You Will Learn:
Themes Covered in the Podcast:
Quick Takeaways:
Follow for more:
Jon Shanks: LinkedIn
Jay Keshur: LinkedIn
Jon & Jay’s startup: Appvia
Charles: [00:00:02] I suspect we’re quite early on the SCAP and I suspect it will get much better. My slight fear from a writer’s point of view is I think it might replace sort of very genius copywriters, which sounds fine, but then where do you get senior copywriters from? But I’m skeptical that it can replace human writing, at least where we are at the moment. But prediction is a mug’s game. Who knows.
Jay: [00:00:31] Hi, and welcome to Cloud Unplugged. I’m Jay Keshur. And today, joining us is Charles Humble. He is the editor-in-chief at Cloud Solutions, a cloud-native consultancy. So we spoke about remote working, cloud transformation, motivations, and technical writing. So quite a broad set of topics. Let’s dig into our conversation. Hope you enjoy the episode. First of all, you’ve had quite a career journey, so it’d be good to hear about how you sort of got into cloud computing.
Charles: [00:01:01] So yes, I started work in 1993, which is sufficiently far ago that we didn’t even have the Internet. So that’s not quite true. We did have the Internet, but we didn’t necessarily have it at work. I don’t have a computer science degree, so I graduated with a degree in English literature and I started working in publishing I decided that publishing wasn’t really for me. So I kind of thought computing was interesting and I started in desktop support. So that would have been about 1993, I think. And then I kind of gradually made my way up. So by about 2004, I think I was working as an architect. And then by about something around 2011, I think I got a job as a CTO. And that year, 2011 year was a really big year for me because not only did I start CTOing, but I also went to, I think it was QCon San Francisco wouldn’t swear to it. And I saw a talk from somebody at amazon.com who was a principal engineer, I think it was a chap called John Rouser and he was talking about how Amazon had shifted to the cloud and how they were deploying multiple times a day. And I forget what number he gave, I’m going to make up a number like sort of ten times a day or something. Now, at the time we were deploying four times a year and we thought we were pretty cutting edge, do you know what I mean? It was night and day, it was 40 minutes in a room and I came out of it just thinking, that’s the future. It was an absolutely extraordinary moment and that kind of sparked my interest in the cloud and in that just whole shift that kind of see, you had the rise of public cloud. You also had the sort of whole DevOps movement and a bit of agile stuff in there and that kind of all kind of mixed together to get us to this point where what we’re now calling cloud native. But that sort of broad approach, how that all came together, So that was kind of my, I guess my kind of journey to here, more or less. I should say as well because I have massive impostor syndrome about this whole thing because I also about 2011, 2012 kind of stopped coding more or less. Maybe it wasn’t quite that early, but it wasn’t long afterwards. So I know a lot of the foundation still and it’s kind of interesting that actually a lot of what we’re talking about is stuff that’s very familiar to me from working on messaging systems in the 1990s and whatever. But at the same time, if you asked me to, I don’t know, write a lambda function in Go or something, I would definitely be sitting there with the manual a bit and scratching my head and going, so how does this work, again? I do still write bits of code but I’m not nearly as hands-on as I used to be. So I would say I’m better at talking theory than—you know, there are much better engineers out there than I am now.
Jay: [00:03:39] I’m probably in the same bucket by now. I definitely feel your pain there. So that’s quite a journey. I mean, 2011, I guess that’s not long after AWS kind of came about and that whole sort of journey. Were you guys quite a sort of early adopters of the cloud? How did you get your foot into it?
Charles: [00:03:58] We sort of were and sort of weren’t. So at that point, we were running on a hosted service so most of what we were building was written in Java and we were running on a Java hosting provider. We did shift some stuff to Amazon so it was mostly around using things like S3 for storage and the real sort of basic stuff. So yeah, we were quite early in that way but we didn’t do I mean it was always a bit hybrid for various reasons. So yeah, that was kind of our starting point, I guess.
Jay: [00:04:29] Nice. And I guess you’ve got a weird kind of role where you’ve got you’re very technical but then you do a lot of writing, obviously from the English literature background that probably puts you in a very small percentage of the world that has both of those skills, right?
Charles: [00:04:45] Yes, definitely a very small niche. More or less random, I think.
Jay: [00:04:50] So tell me a little bit about that, how you’ve managed to kind of get yourself into this sort of computing and English world, and how you found the journey.
Charles: [00:04:59] Sheer luck. So I’ve always liked the language. I’m actually dyslexic and I have a theory that because I had to work really hard like I learned to read late and my spelling was I used to call it wobbly spelling, which is actually a Willie the P reference, which again ages me rather. But anyway, it was really, really difficult for me and I think my kind of love of language and playing with language. And my interest in language was kind of sparked by the fact that I just found it really hard, which interestingly enough, is also kind of, I think what drew me to computing. It was interesting and exciting, but also difficult. I got my first kind of writing breakthrough InfoQ through their news writing program. I forget exactly what year that was, sorry. But what I do remember is I emailed a guy called Scott Delop who was then the head of their Java coverage. And I was talking about something called Google Web Toolkit, which was one of the sorts of early Java to JavaScript kind of compilers. So that’s actually sort of come a bit back into fashion again. But anyway, I’m sort of saying, why aren’t you covering Google Toolkit? was basically the email. And he wrote back to me and said, well, these are my reasons why, and by the way, would you have any interest in being a news writer? And I thought, okay, that’s random, sure, why not? Gave that guy. So I did that for a while. I became the head of Java coverage for a while, and then when I was doing my CTO thing, we eventually positioned that startup for acquisition. So it was acquired by a large consulting firm that I can’t name. I did a year for said large consulting firm and then it was actually like a fateful New Year’s Eve over probably one too many glasses of champagne with my wife. And I suddenly went, I want to see something else. I don’t really want to program anymore, I want to do a different thing. And actually, InfoQ had approached me to be Chief Editor about six months earlier, but I was in the middle of doing this acquisition, so that was never going to happen. So I went back to them and said, are you still looking for a chief editor? And they said yes. And I said, Well, I have no idea what being a chief editor is, but I’m happy to give it a go if you are. And about three months later I studied there and I did that for six years, I think, which I believe I might in saying is I’m still their longest-serving chief editor for my sins. But that was again an incredible experience. I mean, C4Media is a very, very interesting company. It was all remote, it was really quite small, but sort of punching above its weight. And they had a really interesting model which was rather than going and getting IT journalists to write, they went and found programmers and taught programmers how to write. Does that sort of make sense? Which is completely different from how most IT writing happens. And I think it’s a really good model. I mean, it has its challenges, but overall I think it’s a really, really good approach. And I found that interesting because it meant I got to teach people how to write stuff and I found that whole process just kind of fascinating. So, yeah, I was there for six years and then when the pandemic happened, they were needing to cut costs rather rapidly and I was laid off and joined Container Solutions rather fortuitously again. I think my whole career is basically just a series of occasionally very lucky accidents.
Jay: [00:08:04] Correct me if I’m wrong, but C4Media is based out in Toronto. So were you working remotely?
Charles: [00:08:10] Yes, they’re pretty much 100% remote. So there is an office in Toronto, I think it’s got room for three people or something. I went because I was on the exact team for C4 for most of the time I was there. Not the whole time, but most of the time I was there. So I did go out to the office a couple of times, but most of the time, yeah, it’s 100% remote. In fact, the startup, the PRPi, which is the start I was doing before, was also 100% remote. So I’ve done remote only working for probably about half my career now.
Jay: [00:08:37] One of the things I thought would be quite interesting to talk about is your views on remote working because I know you’ve written a fair amount about it.
Charles: [00:08:45] Yes.
Jay: [00:08:46] So obviously COVID has happened since and technology has sort of moved on. There are probably a million different ways to collaborate online. In fact, we’re on one, right, we use Riverside.fm to just make this podcast, which wasn’t necessarily possible sort of years ago, so be interested to kind of hear your thoughts about sort of remote working, how to make teams efficient and especially sort of combining that with moving to the cloud. So big organizations doing a bit of a cloud transformation and setting them up successfully whilst working remotely?
Charles: [00:09:23] Right. Yeah. So, funnily enough, just before COVID I gave a talk about why I thought remote working was good and we should all be doing more of it. So sorry about that, I kind of got my wish.
Jay: [00:09:34] It’s your fault. It was your fault.
Charles: [00:09:36] So here’s the thing, there are a bunch of things about remote working that make remote working great. One of those things is you can hire from a much broader talent pool, right? So if you’ve got a physical office in, say, London, then you can hire people who can get into London. So either they live in London or they live near enough to commute in every day. While if you are working remotely, you can hire everyone in the UK, everyone in Europe, probably the east coast of America, within about four or 5 hours in terms of time zone is generally fine, right? Much more than that. And it starts to get a bit overly complicated. So suddenly your talent pool is much wider. That’s a huge plus. Another huge plus is you can hire a much higher group from a diversity standpoint. And the reason for that is A) some of the people you might otherwise want to hire might be, I don’t know, single parents, for example, with young children and school runs and stuff. And they can’t be in the office from nine till six because they’ve got little Johnny at school and then pick him up again at 3:00 p.m. or whatever it is. Right? So there’s that group of people. You’ve also got people who are on the autism spectrum or otherwise neurodiverse, who again, going into an office every day and having to interact with humans face to face is a living hell. So those people are suddenly available to you that weren’t available to you before or maybe weren’t available to you before. Right? So your diversity pool suddenly becomes much, much broader. There is quite a lot of data that says that more diverse teams will outperform less diverse teams. There are things you have to get right to make that actually true. So psychological safety is one of the main ones. People need to be able to speak honestly and talk about how they’re feeling. And actually that psychological safety in a remote organization, I think is pretty key because in an office you can observe behaviors in a way that you can’t remotely, right? So you need people to be willing to tell you things in order for you to know what’s going on. So if you don’t have trust and safety, right, people aren’t going to tell you things, you’re not going to know what’s going on. So that’s one area. Well, as funnily enough, you can have high-performing teams that are not psychologically safe in office environments. I’ve worked on non-psychologically safe teams that were very high performing. It’s not pleasant, I mean, I wouldn’t recommend it. It’s horrible, but it totally works. Fear can be a motivator. It’s just not one I would necessarily advocate for. Right, so a higher range of people, or a wider range of people, wider diversity, you need to get things like trust and safety right, in order to get high performance. That said, it is also true that remote working doesn’t really work for everybody. The main people that struggle with it, I think, are people who are highly sociable, but also people who are really prone to procrastination. Because at the end of the day, you’re sitting in a room on your own and nobody knows how much time you’re spending reading the Internet. And honestly, if you’re not able to motivate yourself to work, and most of us can do that for a week or a month, but doing that day after day, week after week, year after year, when nobody really knows, is quite hard. So from a management point of view, that means you need to be looking at people’s outputs, what are people producing rather than what are they doing. But from an individual employee point of view, you need to find ways to be able to keep yourself engaged and motivated, whatever those things are.
Jay: [00:12:59] So if you’re kind of early in your career and say you’ve just finished university doing a computer science degree or something like that and COVID hits, right? And now you’re maybe looking for a job or just started one or something like that, in that early first part of someone’s career where they’re kind of learning to be in a work environment, learning how to work, learning to do a job in these hours and try to connect with their colleagues and things like that. That’s hard because you’re learning so many things all at once and then you’re doing it remotely.
Charles: [00:13:34] Yeah, it’s really hard. And I think it’s very easy for me to sit I’m in my office here. This is a room that is away from the rest of the house with my synthesizers to my right and all of that stuff. And I’m incredibly lucky and I know that I’m incredibly lucky. It’s very different if you’re, I don’t know, in a house shared with five rowdy people and whatever. Having said that, it’s better for diversity for a lot of reasons and I do think that’s true. It is also true that for some people it’s really difficult. COVID in particular exaggerated a lot of the problems because a lot of the normal workarounds weren’t available. But your other point is it’s a lot harder to network when you’re first starting your career when you’re working remotely. And also I think learning is harder. There are things you can do as an organization that helps with that. Some of that is around onboarding. So Container Solutions does really smart things like having a buddying system as part of the onboarding process. You sort of effectively have two people who mentor you and get you into the company. Technology has got a lot better. So obviously video conferencing used to be a complete nightmare. It now works pretty well. Most of the coding tools have pair programming options either built-in or there are utilities that you can get for that. Again, that really helps. But again, the organization’s got—remote working. Doesn’t work if you’re not intentional about it. And one of the things I would say as well is, you know, we spent 100 years figuring out how to make offices work. We started remote working. The first remote working example I could actually find like really what we would call work is 1979. It was IBM in 1979. So we haven’t been doing I mean that’s one way that’s like wow, 1979, that’s a hell of a long time ago. That’s extraordinary. And it is, but equally, it’s not that long ago and I think we’re still working out how to do this. But yeah, things like having a really robust onboarding process really help. Cloud-based tools and remote tools in general are getting better all the time. Embrace the things that are there. My whole life now runs on Google Docs and stuff. Can’t do any of the things I do without things like visuals, video conferencing, and so on and so on.
Jay: [00:15:51] Yeah, sure. I guess there are so many sorts of bad things that obviously happened during COVID and we won’t talk about those, but COVID for sort of technology, was a bit of a catalyst in a lot of ways, right, because technology had to kind of meet new ways of working. All of these services are now having to support more users or have different features that allowed that collaboration to happen. I guess another catalyst that I’ve kind of seen is obviously people moving to the cloud, right? So lots and lots of companies moved to the cloud for the first time or had an ambition to and then COVID sort of hit and that was like, okay, we can’t go into our data center, run rack B service or anything like that anymore. We have to think about how to do this. There are so many sorts of motivators for sort of doing kind of cloud transformation, sort of migration to the cloud, and things like that. What have you, I guess, seen work well and how have you seen work?
Charles: [00:16:54] Yeah, absolutely broadly thinking. I don’t think it’s changed all that much. I think there have always been basically three factors. So one is speed, and one is being able to get from the idea I have in my head to the market quickly. So we’re talking there about shifting from taking months to get an idea into production to perhaps days or even hours. And the odd thing about that we now know, which we didn’t know like ten years ago, is that it turns out that software is kind of weirdly anti-physics. So we have this really deep-rooted thing in us as human beings that when something is risky, what we want to do is slow down, right? So if you’re driving and it’s pouring with rain or it’s snowing or the road is icy or something, I hope you slow down to allow for the road conditions. Or I don’t know, you’re walking across a wobbly bridge above a crocodile-infested river or something, and you walk really slowly because you don’t want to slip off because that would be bad. It turns out in software that moving more quickly, provided you do it in the right way, but moving more quickly is actually safer, which is sort of weird and counterintuitive, but it does turn out to be true. So speed was one thing, and the second thing is scale. So again, I remember lying in bed at night worrying, have I got enough servers to deal with this spike of loathing that’s coming? Or whatever it was? Have I sized this thing correctly? And the shift towards elastic computing got us away from all of that. So if you suddenly find you need to support more users in more locations with a whole range of different devices, and you want to be responsive and manage your costs and not have the whole system fall in the heap. The cloud allows you to do that in a way that was tricky in your own data centers, which is great. And then the third thing is the margin. So a lot of CS clients would be talking about they would have a strategic goal around basically only needing to pay for the resources they actually need. So you might think of something like an e-commerce site where you have a very bursty workload. So like we’re just doing a great big TV campaign that generates a huge spike and then the spike goes away or it’s Black Friday or Christmas or something, right? So we need to go up and down your spending shifts. So it goes from being CapEx, buying new machines kind of in anticipation of success to OpEx say, paying for the services you need and all of that is really powerful. The margin one is interesting though because it’s really easy to get that wrong and there are whole, you know, like the Duckbill Group is a good example. There are whole consulting firms whose job it is to make your Amazon bill come down, which is telling. So there’s usually a point in everybody’s cloud-native journey when they go gosh we’re giving a lot of money to Amazon. I wonder if we could give less money to Amazon and what that would look like. So yeah, the margin is an interesting one. I think at the moment, the margin is kind of top of mind for a lot of companies because of the kind of weird macroeconomic situation we find ourselves in where we’ve had historically low-interest rates for a very long time and suddenly they’re having to go up and that’s causing some instability in the banking sector and everything else. The amount of emphasis that those three things get varies but I think it’s pretty much almost always those three things in some order. Probably the most common thing we get is speed, so we want to go quicker. And in general, I think if you think about an organization, organizations generally will only change if they’re facing an existential threat. If we don’t change we’re going to die. In startups that’s so routine we don’t really think about it. But, because most startups fail for a reason, right, it turns out business is quite hard. So in a startup, you’re pivoting and changing and moving around all the time because you’re trying to find product-market fit. You’re trying to get something that works. And then if you do get product-market fit, you’ve then got the whole new and exciting problem of suddenly everyone wants to use your thing and I’ve got to scale it. Cloud’s great for that. In larger organizations it’s often a challenger coming in. So if you think of something like banking then like if you’re HSBC or something and suddenly a Starling Bank or Monzo comes in who’s born on the cloud and able to do all kinds of things you can’t do because you’re slow and numbering, and that tends to be the trigger for going, gosh, we need to change. You mentioned COVID, and of course, COVID is like a once in hopefully lifetime experience where suddenly a lot of businesses are like, our whole business model needs to shift. How on earth do we do that? And we had companies like, I can name Slight, for example. I can name them because they’re on the website, so that’s fine. So they’re a remote-first company. They help distributed teams share knowledge, especially like a sort of very advanced kind of wiki. And the pandemic for them was a fantastic opportunity. It’s like suddenly everyone’s working at home, this is exactly what we need, but now we’ve got to scale up because we’ve got this massive tsunami of customer demand coming through. And so for them, it was like, how do we scale what we’re already doing quickly? So again, it’s kind of responding to change. The other one that you see quite often is we want to go quicker. And that almost invariably turns out to be cultural. So architecturally speaking, we know how to make you go quicker, right? You have independently supplyable microservices. You have some way of having your infrastructure as code, like a GitHub type thing. It’s held on to version control and whatever, right? Kubernetes containers, all those things, fine. But if you’ve got like a change control board that meets twice a year and nothing goes to production unless the change control board says it, you’ve done all of this work, you’re not going any quicker. It sounds flip, but it really isn’t that kind of cultural change. We sort of saw it with small agile before agile turned into a mass of standing up and serving other nonsense, right? But when it was agile was originally about breaking silos and moving quicker. And again, the same thing. That’s a huge organizational change. It’s a huge philosophical change that companies really struggle with, particularly if they’re large. So what you often find what we often find with the larger clients of CS is they come to us because they want like, you’ve got Kubernetes engineers, we need Kubernetes engineers. Fine. And then after a bit, it’s like actually, it turns out that what we really need is people that can advise us how to shift the way our organization works in a way that means that we can move quickly or whatever the goal is. But it’s typically moving quicker. It’s a really common one.
Jay: [00:23:19] I guess the other kind of thing that I sort of see in this area is security, right? So people have this concept of being on-prem is sort of more secure and more often than not, it’s less just because of how they’ve thought of security. Sort of like walled gardens instead so once you’re over the fence, anything in that garden is up for the taking rather than sort of zero-trust type models that exist now. Do you see much of that, I guess, as a motivator?
Charles: [00:23:52] So I’m going to qualify this by saying security really is not my area of expertise. I’m going to be a little bit careful what I say. We certainly see companies looking at the sort of shifting left, the DevSecOps type model as being a motivator. In certain industries. It matters more than in other industries, so there are systemic risks that come into certain sectors. I mean, we’ve been talking a bit about money and finance and stuff. So if you think about banking, if all of your financial services providers are operating on one of three clouds in one of three regions, and then one of those cloud providers has an outage, that’s really bad. And so there’s not so much a security risk, but it is a kind of reliability resiliency kind of risk, which is maybe a little bit in the same territory. And I think there we are going to see more regulation happening, so we’re going to see a lot more we’re already seeing a bit of this that the Financial Services Authority in England is getting interested in, the EU the same sort of thing is happening. I think what you’ll see there is the regulator starting to mandate you need to be either multi-cloud or at the least multi-region, and being able to sort of impose things on the cloud providers to basically ensure that there’s a level of resiliency. But I think the security question comes up quite often in the context of remote working as well. Are things more risky because everyone’s using their own devices at home? And the answer is yeah. I mean, the attack surface is wider and if your company is not particularly tech-savvy, there are probably things you need to be talking to people about. Like changing their WiFi passwords and running a password management system and not having every password the same. And maybe having a firewall and virus scanning software, like the basics. But honestly, the risk is different, but I don’t think it’s necessarily worse. Again, it just I think it just requires a bit of a bit of thinking. But yeah, so dev the DevSecOp stuff is certainly something that we see. The broader kind of systemic risk is, I think there and I mean, there’s a whole area of cloud-native security which is, as I say, not my area of expertise, but it is really fascinating. But it’s sort of what you’d expect. It’s defense and depth and all the normal kinds of things that you would hopefully assume. So I don’t know that it changes things radically. Yeah, as I say, I think a lot of that is a psychological idea of all if the data is in my data center, it’s safe. Well, hmm, maybe.
Jay: [00:26:38] Yeah, exactly that. So I guess we spoke about motivators, right? And probably you have a handful of them, and they’re roughly the same in a lot of organizations. So let’s say you kind of prioritize them and you know what you’re going for, and now you’re starting this sort of cloud journey. If you were to sort of say five or ten things that companies that you’ve seen fail as sort of cloud adoption, what would you say they were and how to avoid them?
Charles: [00:27:08] Oh, what a great question. So from a software point of view, often the things that go wrong are things like not thinking about your service boundaries very carefully when you start. So if you’re breaking a monolith down into microservices, why are you doing that? Well, probably because you want to end up with independently deployable units. If you break your monolith into microservices, but then you have to deploy all of your microservices at the same time, you’ve only made everything worse, right? You have gained nothing. And again, that’s harder than it sounds. So figuring out service boundaries is tricky. Ending up with things that are genuinely independently deployable is tricky. Distributed computing is really hard. So that’s one area. Another area is the sort of big bang. We’re going to do all of this all at once, always never works. Never do that. Start with something small and discreet that you can break off. We have a pattern at CS we call gradually raising the stakes, but it’s essentially starting with something small, doing the small thing, proving it out, learn the principles, and then start adding to that. And if you’ve got a large monolith, your large monolith can carry on running and carry on serving whatever traffic the rest of your system isn’t serving for almost as long as you want. There’s like a strangler-type pattern where you basically gradually shift more and more traffic to a new thing and away from the old thing, but you can flip back to the old thing if it dies. The sort of sudden cutover thing, again, is a mistake I have seen companies make. It rarely works. If you’re trying to make a change, that is a cultural change, that’s only going to happen if your senior team, your leadership team, is really committed to that. There’s no other way it’s going to happen. So if we as a consulting firm are going in, we kind of need to know who our C-level backers are and keep them on our side. And they need to stay focused because one of the other things I found, particularly in large companies, is that the company has a kind of it’s like a spring or something. You can sort of pull it and then you let go and it springs back to whatever state it was in before you started messing around with it. People don’t like to change. They really don’t. And so your executive has to be really focused on making the change happen. They need to be clear about what they’re trying to achieve and why? And they need to stay focused because if their attention shifts somewhere else, everyone goes, oh, well, they’re not really looking anymore, this will be fine.
Jay: [00:29:43] It’s funny, right? Because in these types of things, especially when there’s like external consultancies and things like that, you’d expect the executive to be signing off to spend or whatever it is to do to this big sort of transformational thing. But then they almost forget to a certain degree why they’re signing those checks and then need to be kind of reminded or need to be sort of refocused on the outcomes that it’s delivering. What have you, I guess, seen when that happens? What have you seen sort of work well, to kind of realign them or build a real sort of momentum around that executive leadership?
Charles: [00:30:17] That again, it’s really tricky. A lot of this does come down to relationships at the end of the day. At some point, you need to sit down. So this is a terrible answer because I wouldn’t go there from here kind of answer. But one of the things is if you start with really clear objectives so what is it we’re doing? Why are we doing it? And have that as like a bunch of KPIs or something that you could measure and you want those KPIs to be things that make sense to the business, right? It’s no good saying I want to reduce the number of times my application is going to crash because why would I care, right? If I can say I want to reduce the number of times my customer is abandoning the checkout process of my e-commerce app because 20% of our customers are abandoning or something. If we could get that down to 10%, this would be X million of additional revenue and this amount of additional profit right now, there’s a number we can get behind because that makes sense to me as a business. The technical people know that’s about reducing crashes or increasing resiliency. The business people understand the metric, right? That’s kind of, I think, how you have to go. So a lot of the time, one of my kind of pet peeve things is when I hear IT people like technical people going, oh, well, the business won’t support me to pay down technical debt, so well, of course, they won’t. I have no idea what that means.
Jay: [00:31:40] Yeah, exactly.
Charles: [00:31:41] Why would I do that, right? And it’s really let’s blame if we can’t blame marketing or blame management. It’s a classic way that engineers like to think because it’s comfortable and easy. But the reality is, as an engineer, certainly if you’re like an engineering leader, then part of your job is you need to find the way to explain to your business, to the people that at the end of the day are paying you to do the thing why the thing you want to do matters. And if you can’t do that, maybe you shouldn’t be doing it. Because sometimes it’s like, why do you want to rewrite this thing in Go, well, because I kind of want Go on my CV. But that’s probably not a great reason. We’re all a bit occasionally guilty of resume-driven development, but you know what I mean? There are poor-man fixes.
Jay: [00:32:24] 100%.
Charles: [00:32:26] So if you can’t justify it in business terms, the business isn’t going to go with you. And all the normal things keep communicating. Keep telling people what the status is. This is what we’re doing, this is where we’re going. Why communication is so important. And people really miss how important it is. And particularly, actually in remote organizations where it’s mostly written communication, and being able to communicate clearly in written forms, in multiple different written forms is absolutely crucial.
Jay: [00:32:57] Which is great, right? I guess that kind of almost leaves a full circle back into talking about sort of technical writing and trying to give people those skills because it feels like that’s a real sort of gap. So you mentioned that at InfoQ you guys used to train technical people and help them get better at communicating the written word. If we had some people that were sort of quite interested in that, in that journey, where would you get them to start?
Charles: [00:33:28] So there are parallels between writing and programming. Both of these things are basically a craft. I think a lot of the time when we’re at school, we kind of get divided into being like sciencey people or mathsy people or artsy people. And it’s a bit arbitrary and I’ve always kind of thought it was a bit of nonsense, but it’s kind of what happens. So at some point at school, you’re told, oh, you don’t have a gift for writing, which is absolute rubbish, but you were probably I mean, I was told it, lots of people were told it. The reality is it’s a craft. It’s a craft you can learn, but you do have to want to learn it. And some of the parallels are almost embarrassingly obvious. Like with programming, you get better at writing the more you do it. If you want to get really good at writing, write something every day, you’ll get better. You improve through feedback. So with InfoQ I don’t know if they still do, I’ve got to be honest. Hopefully, they still do. But they used to have a brilliant system where you would basically be paired with a journalism professor and also someone who knew your subject and you would do like a news post, 500 words. It’s quite easy to do. I mean, lengthwise, it’s relatively easy to do. And then those two people would review. So it’s a bit like pairing in programming. And again, you do like two or three or four or five iterations, and eventually, hopefully, it would be published, rinse and repeat. You also learn through imitation. So when I was learning to program, again, really showing my age, when I was back, in short trousers and the Commodore 64 was the coolest thing in the world. You go and buy magazines called things like Input, and they would have listings, like sort of line numbers and stuff, and you would type them in and then figure out what they did. And now you probably do the same thing by, I don’t know, browsing open-source projects in GitHub or whatever it is, right? But the point is, you’re learning through imitation with writing. If there’s a writer whose writing you admire, try and copy it. Write about deploying Kubernetes deployment strategies in the style of, Ernest Hemingway or something. It could be a thing. You probably won’t publish it, but you’ll learn tricks and techniques by doing it, and that’s useful. And then the other things are things like your subconscious mind does more programming and indeed more writing than you think. So if you get stuck, rather than spending hours going, I can’t make this work, go for a walk. Walk around the block, whatever, come back, take a break, and you’ll probably find you get it quicker. And then there are also patterns that you can learn. So there are about four or five really common writing patterns. And I would think of like the design of the Gangs of Four Design Patterns book, which I read at some fatal point, and then kept sticking decorators in places where they weren’t needed and whatever. But my point is, like with patterns, you can overuse them, but also they’re really, really helpful. So there are a few standard ones InfoQ news writing uses something called the pyramid of news, which is a very, very common pattern. And basically, the idea is you start with the most newsworthy thing and then it’s like an inverted pyramid of importance. Does that make sense? You start with the most important thing and work down. What’s brilliant about that technique is it teaches you the importance of a lead. So a lead-in, like, a blog or a news post is typically the first sentence or the first paragraph. And the reason it matters is that if you’re really, really lucky, your reader might read the second paragraph. But any of the first paragraphs are interesting enough, right? So your first hook is always going to be the headline, and the headline really matters. At least we could think about things like Twitter, where you don’t have headlines. But in normal blogging and stuff, headlines really matter. Tends to be what the search engines find. It tends to be the first thing you see. If you go to the article, the first paragraph then needs to kind of hook and draw you in, and then each subsequent paragraph needs to be doing the same thing. So it needs to be kind of drawing you through the piece, assuming you want someone to read all the way to the end. In fiction, we talk about opening lines. Douglas Adams the story so far in the beginning, the universe was created this has made lots of people very angry and has widely been considered a terrible move or something like that. I might be slightly misquoting it. It’s a brilliant first line, you’ve got to read the next thing. Yeah. Or George Orwell, 1984. It was a bright, cold day in April and the clocks were striking 13 again. You kind of like, I want to read… And that’s the point, right? It acts as a hook. Drafting. Please don’t send me your first draft. Yeah, the second draft is fine. Don’t send me your first draft. I have a pathological fear of empty web, white pieces of paper. So when I do my first draft of the thing, I’m just throwing words at a screen, really. And then after that, I’ll then work on how I shape it and how I make it work. And that’s like the second process and the third process, and that’s really where the craft comes in. I personally find it’s much easier just to do work that way. Some people like to really carefully plan things out. I’m not one of those people, but whatever you do yeah, drafting is really, really helpful.
Jay: [00:38:15] I guess. Let’s maybe finish up with maybe the opposite of that, right? Because I’m sure in your position you’ve seen good writers and you’ve seen bad writers. So it would be really good to kind of finish up with what to avoid doing if you’re kind of getting into a sort of technical writing or things to stay away from.
Charles: [00:38:36] So sort of writing anti-patterns. That’s a lovely one. Okay, so let’s see. When everything is an acronym, that’s a very common industry disease. There are a couple of things with that. So using terminology consistently, so if you’ve got, I don’t know, protocol buffers or something, don’t randomly rename protocol buffers proto bufs unless you’re fairly confident that your audience knows that the two terms are interchangeable. If you’re introducing an unfamiliar acronym, spell it out and then put it in parentheses afterward. And then you can use the acronym fine. Don’t use too many acronyms. The CFP and the TLD and the sort of three latter acronym disease is a good one. And then the other thing is clear writing is simple. I’m going to make another programming parallel here. So I always think that the essence of programming is to create the illusion of simplicity. Like, if you’re really doing it well, your users should have no idea how hard that was. And in writing, we as an industry, have a tendency to make things sound desperately complicated because we think it makes it sound frightfully clever and terribly important. We’re not going to call a spade a spade when we can call it earth inverting horticultural implement to dig or something, right? Don’t do that. Clear writing is clear thinking and it’s hard. A clear sentence doesn’t happen accidentally. You need to remove all the craft, remove all the clutter, and you end up with something that is that I should be able to read without understanding the subject. There’s a wonderful book by a man called William Zinsser called On Writing Well which was probably the best thing on writing I’ve ever read he says that good writing is lean and confident and I’ve always loved that. So yeah, that’s a really good one. He also says that the secret of good writing is to strip every sentence to its cleanest components. Which again I like. And again I think there are parallels in programming here. I think if you’ve ever I mean, I’d love to say I wrote code like this that will probably be an exaggeration, but I’ve certainly seen code where you look at it and, like, everything is beautifully named and every function does, like, one thing and it’s really clear what it does and structures it. And with writing, it’s kind of the same. There is an aesthetic to it and this is specifically for technical writing and that aesthetic is about clarity and draft and draft and draft. You’ll know when you got it right.
Jay: [00:40:54] Is there anyone that you kind of look to yourself and think oh wow, that person is a great technical writer? I mean you’re probably up there yourself, right?
Charles: [00:41:03] I’d love to think I am, but I don’t know about that. Not so much an individual writer that I can immediately think of. I will say that Microsoft’s technical documentation is on the whole outstanding and always has been in a way that Amazon is not. Microsoft has always had a real culture of that and I think it goes all the way back to I mean I remember programming on Windows and obviously, it was completely closed source and if you wanted people to adopt it they had to know what it did. And so the Windows API docs were extraordinarily good and still are and you kind of see the same thing with Azure now that if you want to know how an Azure function works go and look it up on MSDN or whatever it’s called these days. Again, it’s clear and it’s very concise and it’s very beautiful. There are some very good tech writers around. Tim Anderson, who writes for the Register I greatly admire, and Joe Fay is another one I admire. Jennifer Riggins is very good. So there are some great people around. But yeah, in terms of sort of like a big obvious one, I would go and look at Microsoft. I think they do it genuinely and that’s quite painful for me because I grew through the whole browser wars when Microsoft was the evil empire actually they might have been evil but their docs were great.
Jay: [00:42:20] Yeah, well, you know what? I think with all of the things going on with ChatGPT and the integration to being in Edge and all that kind of stuff who knows? I think the browser wars are back on.
Charles: [00:42:32] It’s going to be very interesting times if it’s very interesting for a writer, actually, the whole ChatGPT thing.
Jay: [00:42:37] That’s what I was going to say is like all of those patterns that you’ve kind of talked about, or anti-patterns, you’ve now got a thing that can put some of it together. Even the thing that you talked about, was Kubernetes deployment strategies written by Ernest Hemingway. I guarantee that someone listening to this podcast is going to…
Charles: [00:42:58] Someone’s going to throw it into ChatGPT and see what it produces. Yeah, for sure. I think it’s really interesting. I don’t know where we are on that S curve and it’s sort of kind of a bit exciting. It’s very exciting. But as a chap on the wrong side of 50, there’s also a bit of me that’s finding it slightly alarming.
Jay: [00:43:15] Damn it. This would have made my job easier. Exactly.
Charles: [00:43:18] It’s interesting. I mean, the main observation I would make about ChatGPT at the moment is I think that the applications that are being put to on the whole are probably the wrong ones because it’s prone to hallucinations, search is probably not its friend because it makes stuff up, essentially. This is not what you want from a search engine. I would have said I think as a creative spur, it’s potentially interesting. Although I have to say, honestly, I played with it a bit. It hasn’t produced anything that I would use, it hasn’t produced anything that I would even try and edit down to be usable. But I suspect we’re quite early on the S curve and I suspect it will get much better. I don’t think it will replace good writing. My slight fear from a writer’s point of view is I think it might replace sort of very genius copywriters, which sounds fine, but then where’d you get senior copywriters from? So genuinely, I don’t know how that’s going to play out. I do think it’s, as I say, interesting and a little bit scary, but because it has no understanding of it’s just stringing words together based on patterns, right? It doesn’t have any actual understanding of what it’s doing. And so because of that, I always think it’s a long way from being able to replace. It can probably pass off an undergraduate essay or something, but I’m skeptical that it can replace human writing, at least where we are at the moment. But prediction is a mug’s game. Who knows?
Jay: [00:44:48] Is there anywhere that people can find you if they want to reach out?
Charles: [00:44:52] Oh, gosh, yes. I’m on LinkedIn as Charles Humble. I’m @charleshumble on Twitter. I think my DMs are open and yeah, do reach out. I’m always happy to engage with interesting folks. Very happy to hear from folks.
Jay: [00:45:05] Perfect. Well, it was really great having you on the chat, Charles. And yeah, it was really interesting to kind of learn a thing or two about writing. I’m going to Google every single one of those names you’ve just mentioned. So thanks.
Charles: [00:45:16] Excellent. Thank you very much. Jay. That was great fun.
Part of the Appvia family.