In this episode, Charles Humble speaks with host Brijesh Ammanath about skills that can provide developers a grounding in systems thinking.
Charles is a 30-year veteran of the IT industry, including as a former software engineer, architect, and CTO, as well as editor in chief of InfoQ and chief editor for Container Solutions. He has published “Professional Skills for Software Engineers” as a series of 14 O’Reilly shortcuts covering communication, critical thinking, documentation, and networking.
Underlying his work is the idea that as complexity increases in IT systems, the roles of architects and leaders move from linear thinking to something that might be more broadly defined as systems thinking — looking at problems and systems as a whole rather than just the individual parts. This requires a skill set that isn’t generally taught or widely valued as an industry — in part, because it’s hard to test in whiteboard interviews. It requires a mixture of communication skills; interpersonal skills; critical thinking; the ability to synthesize large amounts of information.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
- SE Radio 529: Jeff Perry on Career Management for Software Engineers
- SE Radio 515: Swizec Teller on Becoming a Senior Engineer
- SE Radio 303: Zachary Burt on Freelancing as a Career Option
- SE Radio 281: James Whittaker on Career Strategy
- SE Radio 245: John Sonmez on Marketing Yourself and Managing Your Career
- SE Radio 287: Success Skills for Architects with Neil Ford
- SE Radio 491: Chase Kocher on The Recruiting LifeCycle
- SE Radio 419: John Ellithorpe on the Role of a CTO
- SE Radio 501: Bob Ducharme on Creating Technical Documentation for Software Projects
Other References
- Expert Playlist: Professional Skills for Software Engineers & Architects Shortcuts
- Charles Humble, Conissaunce Ltd.
- All of Charles Humble’s Content on InfoQ
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Brijesh Ammanath 00:00:18 Welcome to Software Engineering Radio. I’m your host, Brijesh Ammanath. Today I’ll be discussing professional skills for software engineers with Charles Humble. Charles is an IT industry veteran with almost 30 years of experience. A former software engineer, architect and CTO. Charles has worked as a senior leader and executive of both technology and content groups. Charles is an experienced commissioning editor, was InFoQ’s editor-in-chief and was Chief Editor for Container Solutions. Charles writes regularly for the new stack already and other publications and has spoken at multiple international conferences. Charles, welcome to Software Engineering Radio.
Charles Humble 00:00:54 Thank you very much. Lovely to be here.
Brijesh Ammanath 00:00:56 Charles, you’ve written a series of shortcuts that will enable developers to improve their communication, critical thinking, documentation and networking skills. What drove you to write these series of shortcuts?
Charles Humble 00:01:08 There’s a kind of a long answer to that and a short answer to that. So the short answer is it’s a project that I had in my head for years and about nine months ago I pitched it to O’Reilly and with them I kind of found a publisher for it. And the basic idea was I wanted to provide a set of resources for junior and mid-level software engineers that cover areas that you are not generally taught at university, but that I think are really important if you want to get into more senior roles. So essentially you can think of it as a set of things that I wish someone had told me when I got my first promotion. And that was one answer to the question, but the other was kind of reflecting over the course of my career. So I learn to program in the 1980s on a bit computer, so mainly the BBC model B and the Commodore 64.
Charles Humble 00:01:57 And at the time we had magazines where people would share things, they’d learn how to do so with the Commodore 64 for example, the screen had a border around it, which you couldn’t do anything with. I mean you could change the color of it, but you couldn’t put graphics into it. And then at some point someone figured out how to put graphics. So put Sprites into the border by using a bit of assembly code and an interrupt timing trick. And then they described how they’d done it in the magazine, which meant that we could all learn it. And that was kind of my first exposure to computers in the industry. Really it was how I learned program. And then when I joined the industry as a professional, which was in the sort of about 1994, I think that was sort of didn’t really happen anymore.
Charles Humble 00:02:33 It was like code had become this kind of secret thing that we didn’t really talk about. And obviously open-source has changed that to some extent, but I feel very strongly as an industry we need to get better at sharing our knowledge and our experience because so much in the industry is quite kind of nascent and poorly understood. Years later, as you said, I joined in InfoQ as Chief Editor, which was a position I had for about six years. InfoQ has this really interesting model in that essentially what they do is they take programmers and they train them how to be news writers and then how to write news. So most tech websites will have tech journalists, so professional journalists who writes about technology. Well as in InfoQ has professional developers who have learned how to write. And so I spent a lot of time basically training engineers how to write better.
Charles Humble 00:03:22 And what I realized was an awful lot of them had this kind of weird fear of writing because they’d been told at some point that they weren’t good at it, that they didn’t have a gift for words, which just seems like a terribly unnecessary burden to carry through life. And it’s nonsense. Programming and writing are both crafts and therefore like any craft they can be learned. So about two years ago I wrote a conference talk called Writing for Nerds. And essentially what I did was I talked about writing in house do it, and I gave it a couple of times I gave it a go to and I gave it a DevOps in the UK and each time I had a packed room, which surprised me, but it kind of implied that there were people who were interested in this. So I kind of thought, well maybe I should do some writing about writing for engineers, writing as an engineer rather than writing for an audience of engineers.
Charles Humble 00:04:12 And then as I sort of found myself reflecting on writing and on the other skills, so communication systems thinking and so on and how all of those things sort of intersect. So that was really the longer answer. That was really the starting point. And as I said, I pitched it to O’Reilly, we played around with it for a while and eventually ended up with a set of these 14 connected articles. So what they call shortcuts between about a thousand and about 2000 words on average. And that’s the stuff that you find on the O’Reilly platform and they seem to have been quite popular. I’ve had some lovely feedback on them at least. So they found an audience and hopefully it’s a useful resource for people.
Brijesh Ammanath 00:04:48 That makes perfect sense. We’ll deep dive into each of these themes over the course of this podcast. What are some of the common communication challenges that engineers face within teams?
Charles Humble 00:04:59 So there are a couple of different things that come up all the time. One of them is meeting proliferation. And that happens particularly in remote settings. So that’s basically where you feel like your entire day is filled with nothing but meetings essentially. And there are a variety of reasons why that breaks flag for people. So part of dealing with that is thinking about the where synchronous communication, so meetings, whether that’s in personal or online is the right thing, is the correct thing to do. And where asynchronous communication, whether that’s via Slack or email or something like that might be a better method. I think in general, the sort of point with this sort of stuff with communication in general is to be very deliberate about what you’re doing and why you’re doing it. So think about if I’m going to have a meeting, who needs to be there, can I put an agenda together so people know what to expect?
Charles Humble 00:06:03 How long do I think I need kind of avoid? We sort of automatically tend to default to an hour or something. Does it need to be an hour, or can it be 40 minutes? So those some of the things I think it’s very helpful to have some sort of actual communication policy. So these are the channels we use when we need an urgent response. These are the channels we need when we use, when we need a less urgent response. An awful lot of this stuff, as I say, is really about being deliberate and thinking about what is the right method of communication to use for this particular thing. I also have a whole section on empathy, which again I think is really key to a lot of this, which I can talk about a bit as well. But yeah, just thinking about what’s the most efficient way to get this across to a team of people is probably the starting point.
Brijesh Ammanath 00:06:55 Right. How does empathy help improve collaboration between engineers, especially in high pressure or tense situations?
Charles Humble 00:07:03 Yeah, I think empathy is incredibly important. I think there are a whole variety of different situations where empathy really, really matters, but anywhere where communication can be a little bit difficult or if you’re thinking in product senses where you are trying to understand what the customer experience is like, understanding how to, so I’m using empathy here to mean basically taking someone else’s perspective and knowing how to do that. It’s incredibly helpful when you’re designing products. It’s also incredibly helpful in any situation where you have team conflict or disagreements between team members. It’s incredibly helpful when you are working with stakeholders that maybe aren’t in it or maybe in a business background. I really, really think it’s absolutely key and it’s something that you can learn how to do. I think lots of us kind of know how to do it instinctively, but not everybody does. There are exceptions to this, but in general there is quite a strong evidence that empathy in my sense I’m using it here, is a skill that most people can learn how to do. So I think again, taking the time to do that is helpful. It’s helpful when you’re working on products. It’s helpful when you’re working on teams and so much of what we do is collaboration at the end of the day and empathy is a really key thing for being able to collaborate effectively.
Brijesh Ammanath 00:08:27 Couple of thoughts come to mind, but before I jump to the next question, do you have any techniques to improve empathy?
Charles Humble 00:08:34 Yeah, I actually go through something of a practical exercise in for learning how to do it in the relevant shortcut. But in brief, the first thing to do is to actually start reflecting on your own responses. So if you respond to something in a slightly unexpected way, take some time to reflect on why that is. For me personally, I have a thing that I tend to have quite strong emotional responses, so my emotions get quite big on me quite easily. And so it’s something that I had to learn to do in order to be able to control my emotions. And you can treat it like a data point like you might in a malfunctioning system or something where you basically sort of step back and go, well that’s a weird response, why am I responding that way? So that’s the first thing, get used to your own responses.
Charles Humble 00:09:22 The second thing is to get much better at listening and really listening. So being properly attentive, trying not to entrap when someone speaking, when they finish, try and reflect on what they’ve said and make sure you’ve really understood it. So you can use techniques like mirroring where you basically rephrase something back to somebody. So did you mean this? Don’t be afraid to ask questions if you’re not sure. And that by the way, that’s so valuable because we are, as human beings, we are so distracted all the time. So it’s super valuable in a work context, but actually it’s amazingly valuable in your personal relationships as well. People really value that sense of being properly listened to and properly heard. So those things are a really good starting point. A lot of this is just about making stuff that you may do instinctively a conscious practice and thinking through what it is I’m doing and why am I doing it. And that’s the stuff that really makes a difference.
Brijesh Ammanath 00:10:18 So let me try mirroring your response to make sure that I’ve understood what you’ve said. So the key techniques of improving empathy that stood out for me, one was, reflect on your response to ensure that you’re able to control your emotions. Number two was be better at listening, which is, be really attentive and do not interrupt. Third was mirroring, summarize what you understood to make sure the other person agrees to that. And the third most important point was don’t be afraid to ask questions.
Charles Humble 00:10:50 Mm-hmm .
Brijesh Ammanath 00:10:51 Continuing with the theme of communication, you also mentioned that when you’re communicating with stakeholders, it’s important to pivot these conversations around outcomes. Why is that?
Charles Humble 00:11:03 As a rule of thumb, business people don’t care very much about technology and as technologists, that’s quite a hard lesson in a way that’s quite a hard thing to accept. Because we as industry professionals get very excited about the way our systems are built, the architecture, the cleanness of it, the expressiveness of our code and that sort of thing. The business doesn’t care about any of that stuff. What they do care about is they care about results; they care about what the consequences of what you are doing are. So I have in my consulting job, I have had so many conversations with people that have been along the lines of, I’m trying to get the business to sponsor me to pay down technical debt on this application and the business won’t do that. And it’s so frustrating and you’re like, well, have you explained to them what that even means?
Charles Humble 00:11:48 Because if you haven’t, they probably have no idea. In fact, technical debt is really bizarre to me because we think of it as quite a useful metaphor, but it really isn’t. I didn’t mean it helps anybody. I mean even IT people, I’m not sure if you sat down with a bunch of programmers and said, what does technical debt really mean? I suspect a lot of them would struggle to really describe it other beyond, you know, getting rid of things. I don’t like the term is every bid is meaningless to a business stakeholder. So if you frame things in a way that makes sense, so in the shortcut, I use the example of, I can’t exactly remember but it’s something like we’ve got 10% of our customers are abandoning arts on the Android app at checkout and we think that’s because of the app is freezing or crashing or something.
Charles Humble 00:12:31 We think that’s costing us X amounts in revenue and we reckon it will take us about four weeks to try and fix it. And you as an IT person know what I’m actually going to be doing is fixing a bunch of accumulated debt in that application, which is there because I wrote the thing too quickly in the first place. But the important point now is that the business has a reason to sponsor you to do it and a reasonable understanding of what the expected outcome is. And it also of course means they can hold you to account. So if you go away for four weeks and come back and the app is still crashing or customers are still abandoning you at the checkout, you’ve then got a reason to go and look again and go, okay, well that didn’t work, so what’s really going on here because we actually sponsored you to solve the problem.
Charles Humble 00:13:15 So that’s the point. It’s getting away from this idea that at the end of, I don’t like the division between the business and IT because I think it’s unhelpful at the end of the day, we’re all part of the business, right? But it’s just thinking about expressing things in a way that makes sense to the other person’s context so they can make informed choices and right choices and hopefully the choices may be the ones you want or at least if they’re not the ones you want, there’s a good reason. The other part of that is if you can’t come up with a business justification, maybe you shouldn’t be doing it at all. You know, if you are sitting there thinking, I don’t know, I want to rewrite our entire application in Rust or Go or something and it’s currently written in Java and you can’t justify that in business terms, well maybe you shouldn’t be doing it and that’s not a bad thing. You might not like it but it’s not necessarily a bad thing. So I think that’s the other sort of side of the same coin.
Brijesh Ammanath 00:14:06 I think technology depth is a very good example and how pivoting to outcomes gives us a mechanism to measure it, the delivery. In your shortcut you also give a very good example on why it’s important to talk to customers. Most of the software engineers are introverts. Don’t want to generalize them, but that’s the case. Why is it important to talk to customers?
Charles Humble 00:14:28 I had a really great experience on this very early on my career actually. It was for a retail bank in the UK and it was specifically for the call center and this particular retail bank, I can’t name them unfortunately, but basically there were two banks that have merged and they had two separate mainframe systems that were two separate banking engines and they had their call center staff basically sitting in front of a pair of green screens, so think sort of 1970s dumb terminals with incredibly cryptic information on them and we were bought in. So my team was bought in to basically replace that with a web-based, easier to learn, prettier looking front end and that all sounded fine. And we did a bunch of work, and we had some beautiful, beautiful looking web screens and we thought this is absolutely amazing. And then we took it into the call center for the first time and the call center absolutely hated what we’d done.
Charles Humble 00:15:29 It was really kind of shocking. They just laid it. And the reason that they laid it turned out to be that the way a banking call center typically works, you go through a process called ID and V. So basically you ring the bank, you go through a verification process while that’s happening in the background, the information about that customer is being loaded up. So by the time you clear ID and V and land on a call center land with a human in a call center, that human has information about you in front of them. With the green screens, the call center person had literally everything, every answer to every question you were going to ask them on one of two screens and they could all tab between the two of them. While as with our system they had, you know, maybe 10 or 15 or 20 different places they had to go to get the same information.
Charles Humble 00:16:22 Our system was much, much easier to learn because the green screens had a learning curve like a brick wall. But the point was that once you knew what all the cry acronyms meant, all you needed was one of the two screens. And what was so interesting about it was the call center staff were being measured on how quickly they closed the calls. And yes, the learning curve was harder, but with the green screens, the time it took them to close each call was much, much lower because they didn’t have to go off and keep clicking and looking at multiple places. And if we just spent a bit of time sitting down and talking to them in the first place and understanding what their world looks like, we would’ve had a much better idea of how to design the web system in the first place. But as it turned out, that hadn’t really happened.
Charles Humble 00:17:05 There were a lot of people who just kind of assumed they knew and knew that this would be better. It’s a really, really good example. So often I think your understanding of somebody else’s world and what somebody else might want from a system is just going to be wrong. And unless you take the time to talk to them to understand their position, you are going to end up building the wrong thing. And then it doesn’t matter how well you build it, it doesn’t matter how good the code is, how efficient it is, how good the architecture is, you’ve built the wrong thing and everyone’s going to hate it.
Brijesh Ammanath 00:17:38 So it’s important not only to talk to your customers but also to frequently demonstrate what you’ve built. Let’s transition to the next set of our theme of shortcuts, which is around critical thinking skills. In your shortcut about systems thinking, you give a very good personal example about how you transitioned from linear thinking to systems thinking. Can you walk our listeners through this journey?
Charles Humble 00:18:00 Yeah, so again it kind of links back to the Commonwealth 64 experience, which I mentioned right at the beginning. So when I was learning to program, the programs I created were linear and they were easy enough to reason about And what I didn’t, I didn’t know it at the time, but what I was learning was a very specific approach to thinking about software. And that approach is called productionism. I can summarize that basically as being the idea that a complex system is just the sum of its parts. What was interesting was when I worked on my first distributed system, so that was building an internet app for UK High Street Bank in the early 2000s. And with that banking system we basically had, it was a message Kubo system, so it was running on top of IBM MQ series and we had a set of what we called elements which were like small programs that basically rent, they were single threaded and they rub messages off key and that was brilliant because they were very easy to understand as individual bits of software and you could scale them up and down very easily because all you needed to do was to start more instances of them and then you would be draining the queue quicker.
Charles Humble 00:19:09 So that was fantastic. But what was odd about it for me was that I found the business of understanding what the system was doing became much harder. So even though I could understand what the individual elements, what the individual little Q serving Q reading programs were doing, I was very, very hard to get my head around what the overall system was doing. And the reason for that was because all of the complexity was actually in the interactions between the different elements and how they behaved. And if you think about modern software, that’s basically what we do. So the majority of modern software is built from a set of what are event driven, independently deployable services that can evolve at different rates. And what that means is that the skills we learn through reductionism, they’re still useful, they’re very useful when you are creating the individual services but they sort of fall down when we’re trying to reason about how the system as a whole behaves.
Charles Humble 00:20:08 That was the kind of example that I give in the in the shortcut and it’s really paying attention to the relationships between things. So rather than with a microservice understanding what the individual microservice has done is generally pretty straightforward. But understanding how the microservices as a whole behave is more complex. And it’s complex because you get these sorts of emergent behaviors as a consequence of the way the systems interact. Another way to think about it is the system is no longer where some of its parts, but it’s the product of its interactions. So yeah, that’s the example I give in the shortcut.
Brijesh Ammanath 00:20:41 The other thing I liked about your shortcuts is the links that you provide. They’re very relevant and make for very interesting reading. I read one particular code which stays in my mind, I’m not sure if it was in the actual shortcut or if it was one of the links that I followed through. It basically said that because you understand one, you think that you also understand two because one and one make two, but you forget that you also need to understand, and.
Charles Humble 00:21:08 I think I do quote that in the actual shortcut, it’s from Donella Meadows. Her book, which is kind of a classic text which is called Thinking in Systems. Thinking in Systems is it’s not an IT book as such, but it is a book about systems thinking and it’s really, really good. And yeah, I love that quote too. I also link to another book by Diana Ian called Learning Systems Thinking, which is kind of taking some of Danella Meadow’s ideas and applying them in a more IT oriented way. So that’s another really, really good text on the subject. And there’s a quote from her that I really like, which is the role of a systems architect is to synthesize ideas, not dictate what to think. So my goal is to empower people to thrive because I depend on everyone’s knowledge to succeed, which is very much what a system does.
Brijesh Ammanath 00:21:57 The role of a systems architect is to synthesize ideas and not dictate what to think. A very relevant quote, a very good point. Something which I will remember as well. Moving on to feedback, can you expand on what role does feedback play in sharpening an engineer’s critical thinking skills?
Charles Humble 00:22:16 So I can give you a very personal story about feedback actually. So around 2008 I think I was lead architect for a startup in the insurance sector. It was a very intense job, it was very enjoyable. I had 50 or so people in a room, they were all working flat out trying to build basically a life insurance system in a box. And I had a huge disagreement with one of the business analysts on the project and I thought I was just putting my point across. But my manager pulled me aside afterwards and said, you know, basically we hired you because of your passion but you need to realize that you are shutting down discussion. And I was so cross and the reason I was so cross was because I knew he was right, and I had to reflect on it quite a bit because it was one of those things I had to learn to manage about my own personality because I genuinely had no idea that that was how I was coming across.
Charles Humble 00:23:12 So I owe him, I owe that particular manager a huge debt of gratitude for letting me know that I was out of line and giving me the opportunity to reflect on that and correct it. I think in general as managers giving that sort of feedback is hard, right? None of us like doing it. I do not like doing it. And when you receive that kind of feedback, that’s uncomfortable as well, right? No one wants to be told that kind of thing. But I think it’s one of those things, it’s so valuable for people to be able to tell you aspects or the impact of aspects of your behavior that you might not otherwise be aware of. And I think that in the context of critical thinking or critical thinking is a lot of that’s about weighing evidence. So you can think of it as an example of I’m suddenly given a bit of evidence about myself that I wasn’t really aware of and then I can go through the same kind of process in terms of evaluating that, taking it on board and thinking, well how do I course correct that particular bit of behavior?
Brijesh Ammanath 00:24:15 Are there any exercises or techniques that engineers can use to develop their critical thinking skills?
Charles Humble 00:24:22 Yes, there are. There’s essentially a set of things that make critical thinking up. So a big chunk of it is really thinking about how you evaluate. So with problem solving, basically the secret of problem solving is to come up with a set of potential solutions rather than just one. The mistake a lot of us make early in our careers is we come up with a solution and we go, that’s the solution and we go from there. The right thing to do is always to come up with a set of potential solutions and then try and solve ways and then try and decide which one of those to use. With critical thinking there’s a bunch of methods that you can use to do that. So the best one is to write an AB test. The problem with doing an AB test for everybody is kind of like a best-in-class thing, but they’re also quite heavy write but quite difficult to design well and frustratingly if you don’t design them well and even sometimes when you do, they don’t necessarily give you a particularly clear-cut answer.
Charles Humble 00:25:19 So the second thing you can do is obviously look at correlations in your existing data. It’s less time consuming, it’s not always obviously why two things are correlated. So that’s a bit problematic. You can also look at historical arguments. So has anyone studied this before? If they have, what conclusions did they reach? And then you can also have the collective experience of a team to draw on anecdotal evidence and those sorts of things. So it’s again, going back to this idea of that a lot of these things are about deliberate practice. So a deliberate practice with critical thinking is ask the question, form a hypothesis, gather, and weigh the evidence and basically do those things in a logical sequence. And the thing about learning that approach and learning that skill is it has incredibly broad applicability. So I’ve used it when making investment decisions at an executive level.
Charles Humble 00:26:06 I’ve used it when designing products and features. I’ve used it when dealing with a problem in a team and trying to effectively like debugging a team. I’ve used it when evaluating, you know, should I be using dependency injection for this or should I just, you know, solve the same problem with half a dozen factories? And I use it all the time now when I’m interviewing people and writing and that sort of thing because there’s a helpful technique. It does take practice and it really is just one of those things if you know what it is you’re trying to do, you just have to practice and get better at it, but you get better at it with time and it absolutely is worthwhile.
Brijesh Ammanath 00:26:41 Another quote which stood out for me was your quote and the shortcut on problem solving. And it basically went like a problem well stated, it’s a problem half solved. I thought that was a beautiful quote.
Charles Humble 00:26:55 The actual quote is from GM I think. And yeah, it’s a lovely quote. So it comes from Charles Kettering and he was an inventor, he was head of research at GM and yeah, he says a problem well stated is a problem half solved, which I think is a great, great quote.
Brijesh Ammanath 00:27:13 Can you expand on the four-step process that you have described in your shortcut on problem solving?
Charles Humble 00:27:21 Yeah, so I describe a kind of four step process and that four-step process works with almost any problem. So the starting point is to make sure you’ve identified and can articulate what the problem is. And I think so often we make a mistake of kind of diving in straight away without starting up front and going, you know, what am I expecting to happen and what’s actually happening? So if you think about a bug, what am I seeing? What’s the thing that I’m observing that makes me believe this is a bug and what should it be doing? Having that in your head when you start is a really good starting point. Once you’ve got that, the second step is then to go and basically gather information. And how you do that will depend a lot on the actual nature of the problem you’re trying to solve.
Charles Humble 00:28:07 It might be looking at the documentation, it might be looking at log files or commit history or something like that. Then at that point you start coming up with potential solutions. And as I said earlier, what you want to do is you want to come up with several possible solutions rather than just one and try not to dismiss an idea too quickly. I think it’s very tempting to go, oh well that obviously won’t work. And if you find yourself doing that, spend a bit of time thinking well why won’t it work? Because again, we all have kind of confirmation biases and particular kinds of thinking patterns that we get very used to with coming up with solutions. I use a technical confessional programming quite often. It’s sometimes called rubber ducking and the term rubber ducking comes from the pragmatic programmer book. The basic idea is to try and explain the problem that I’m having to somebody else and that might be a colleague that might be a furlough programmer.
Charles Humble 00:29:00 I will sometimes explain stuff to my wife. I’ve also though explained stuff to my very old cat who is probably fast asleep on another chair in my office or something because it doesn’t really matter who you are explaining it to. The point is by articulating it, by explaining it, quite often you’ll get to the point of going, oh, hang on. So as you are explaining it, you suddenly realize something about it that you hadn’t realized before. I also think there’s something there about trying to articulate something out loud which triggers a slightly different part of your brain and makes you see things sometimes in a slightly different way. So that’s helpful. And then at that point you can move to implementation. So once you’ve got a set of solutions, you’ve picked the solution you want to try, you can then start the implementation of that solution. One thing with that, and again obviously it depends on the nature of the problem, but one thing with the implementation is sometimes when you start implementing, you’ll effectively realize, oh hang on, I’m going down the wrong path and that’s okay. Right, that’s fine. Be prepared to go back and go, okay, well that didn’t work, maybe this is now I’ve got more information hopefully and therefore this other method might be a better method for solving the same problem.
Brijesh Ammanath 00:30:11 So to summarize, the four steps are, step one would be to identify and articulate what the problem is. Step two is to gather information about the problem, whether that’s through documentation, talking to end users. Step three would be to come up with potential solutions. And over here you also talk about a technique called as rubber ducking. In your shortcut you also mentioned this is where you challenge, where the problem really needs to be solved.
Charles Humble 00:30:38 Yes. Absolutely.
Brijesh Ammanath 00:30:39 And step four is where you start coding your preferred solution.
Charles Humble 00:30:44 Yes, yes, absolutely. Absolutely.
Brijesh Ammanath 00:30:48 Now we’ll move on to the next theme of shortcuts, which is around networking skills. When we had a prerecording discussion, you mentioned how networking has personally help you in your career. I found your story about your engagement with in InfoQ and your progress to become its Chief Editor to be very interesting. Can you walk our listeners through that?
Charles Humble 00:31:07 Yes, absolutely. So I originally started as a news writer on the Java queue for InfoQ a very long time ago. And what actually happened was I sent an email to the person who was the head of the Java queue at the time, it was a guy called Scott Lop. And I sent him an email asking him why he hadn’t covered something called Google Web Toolkit and Google Web Toolkit was a kind of transfers from Java to JavaScript and I thought it was interesting. So I sent him an email saying I was surprised you didn’t write about this. And I got a very charming email back from him saying basically here are my reasons why we didn’t cover it. And by the way, have you ever thought about being a news writer? And I honestly hadn’t. And I thought, well that’s very bizarre, maybe I should give it a go because it sounds interesting.
Charles Humble 00:31:51 And so I started writing news for them. I quite quickly discovered that I had a bit of an aptitude for it. And then I became lead Java editor when Scott stepped down and I was lead Java editor I think if I remember rightly for about five or six years. And then they approached me and asked me if I would take the Chief Editor job on. And I turned it down originally and I turned it down for a couple of different reasons. One was that I was doing a startup at the time that was, we were basically positioning for acquisition. So I was very, very busy doing all of the work that that implies. But the second reason is because I’m actually dyslexic and the idea of being a Chief Editor and dyslexic just seems so incredibly unlikely that I couldn’t kind of imagine doing it.
Charles Humble 00:32:33 So anyway, I did the startup, the startup was indeed acquired, I did a year for a consulting firm who acquired us and at the end of that year I desperately wanted to do something else and I had a rather drunken conversation with my wife one new year’s eve where I said basically I want to do something else. They’re not quite sure what it’s, and she said, well what about that Chief Editor job? Are they still looking for somebody? Have they found anybody? I don’t know, I don’t think they have. So I went back to Floyd Marinescu who is the co-founder of C4 Media, which is the company that owns in Forke and said, I finished my startup and I’m available and I’d like to talk to you. And we ended up having two or three meetings and then he said, fine, why didn’t you come and do the job?
Charles Humble 00:33:15 And what was so interesting about it was genuinely I had no idea what being Chief Editor really meant or what it would involve. And it turned out that a lot of the skills that I learned as a CTO particularly weren’t that relevant in quite the same way. A lot of running something like InfoQ is about you have to make many, many decisions but they’re all quite small and in and of themselves they feel quite inconsequential. But over time they have a sort of a cumulative effect. So the trick is you basically have to learn to be constantly thinking about where am I trying to go and does this little, tiny decision I’m making over here move me closer to that end goal or further away? And typically what happens with the CTO type role is you have fewer decisions to make, but the decisions you do have to make tend to be a lot bigger.
Charles Humble 00:34:07 But they’re also a lot more obvious in terms of what they’re not obvious necessarily, but they’re, you understand what the impact is in a way that’s harder with something where you’ve got a lot of small decisions to make. But it was a really fascinating job. I had a very happy five or six years there, it was absolutely fascinating. And doing in InfoQ more broadly just introduced me to so many people and raised my own profile. I opened up so many doors for me in terms of other things that I could go on and do. And that was, yeah, that was really a really great experience I think.
Brijesh Ammanath 00:34:36 Thanks for sharing that very interesting story with our listeners Charles. So the whole journey within InfoQ startup with you reaching out proactively to the Java queue editor asking him a relevant question about the Google web toolkit, the challenge most engineers face is in making that initial contact or how does one overcome that initial hesitation of putting the thoughts out there, especially if they feel they don’t have much to contribute?
Charles Humble 00:35:04 Ah, that’s such an interesting question. So again, it depends on a little bit what medium, you mean if we’re talking about writing, there’s effectively like a little bit of a hierarchy of places where you can publish. So obviously one of those would be a self-published blog, right? No one’s got control over that I believe you can basically publish what you like. The next level up from that would be something like a company blog and the next level up from that would be an article for an actual publisher. So I know O’Reilly or INQ or something like that. And if you’re looking to start writing, then honestly the best way to learn it is just to start doing it and be a little bit self-critical. So maybe start by writing some stuff for a blog that you publish yourself or a lot of companies have blogs or tech blogs that you could maybe write for.
Charles Humble 00:35:54 And with a bit of luck, if it’s a company blog, there’ll be someone that can actually give you a bit of feedback and review what you are writing and yeah, just get a bit of a feel for it, get a bit of experience for it. And then once you’ve done that, then maybe you could think about reaching out to somebody like InfoQ or O’Reilly or whoever it is. With InfoQ, they do have a news trainer program and the news trainer program is brilliant. So what you can do if you go on the InfoQ site, there’ll be a contribute button somewhere and if you can find that, it’ll take you through the steps. But basically you say, I’m interested in writing about this topic. And then what they’ll do is they will pair you with a journalism professor. So someone who can basically do like sort of Basic Journalism 101 type teaching and a subject matter person who can help you with understanding the audience and the technical aspects of it.
Charles Humble 00:36:44 And just by doing that and writing on a regular cadence, so maybe writing a 500-word news post once a week or something like that, you will get so much better. I completely understand the thing of it, it can be hard to take that first step. But the overall thing I would say is, you know, you as an IT professional will have a set of experiences and a set of knowledge that other people don’t have. And I think one of the things that’s really difficult to get your head around when you first start thinking about this is, oh, like I know this but that’s because it’s obvious. Everyone must know this thing and it’s not true. And so often really, it’s having the confidence to go, I wonder if there’s something here, I wonder if there’s something interesting. Try the idea out with somebody that you like that you trust and see what comes back. But as I say, it’s very much I think about just being brave enough to take that first step and accept the idea that you probably have stuff to say that other people would be interested in hearing. You know, we all have to start somewhere if you are a slightly more senior programmer than you’ve got experiences that a junior programmer will learn from. So learning how to share that is a really, really good skill.
Brijesh Ammanath 00:37:54 In your networking theme, you also have a shortcut on getting involved with the community and contributing to open-source. How does contributing to open-source help enhance an engineer’s career?
Charles Humble 00:38:05 It varies a little bit. It’s certainly one of those things where if you think about getting a job then being able to point to an open-source project that you’ve contributed to is helpful. It’s a little bit like, it’s an addition to your CV or to your resume, but I think there’s actually another reason to get involved, which is a little different to that, which is it teaches you how to fit in with the style of somebody else’s project. And when you work in a professional context, that’s actually a thing you have to do all the time. So you learn different ways to how to write your code, how to organize your code, how to build things. And if you’re contributing, say you’re fixing a bug on an open-source project, then doing that means that your code fits in with the code that’s already there and you learn to do that no matter what your personal preference is.
Charles Humble 00:38:58 And it’s a really fantastic learning opportunity because that’s such a difficult thing to teach. So you know, like an experienced university lecturer can explain algorithms and languages and all of those sorts of things really, really easily. But what’s much harder to get across is things around aspects of structure and taste and those sorts of things that really start to matter on a big project and they matter on a big project because on any large project the sort of fundamentals are down to collaboration. So that’s part of it. I think the other thing is you also learn aspects of interaction. So, so often and when things break down in open-source communities, it tends to be because someone comes in with a very opinionated view on a thing that doesn’t fit with the rest of the project and you have a maintainer with a sort of broad mental picture of how the thing should work and you are coming in and suggesting a fix, but you have to fit in with their model and you don’t get to tell them that they’re wrong, if you see what I mean.
Charles Humble 00:39:54 A lot of the way we learn to code actually in the same way as how we learn to write is through imitations. It’s learning how to basically mimic another person’s writing style and gradually over time you’ll learn what works for you and what you like and what you don’t like. So I think learning how to adapt to people’s coding style is just such an invaluable thing to do and I think that’s kind of a key part to it. So the short answer is it’s a nice thing to be able to put on your CV and that sounds like a good reason, but I actually think again, particularly if you’re sort of at that relatively early stage in your career and you hadn’t worked in a lot of companies or worked on a lot of different projects when that sort of learning how to fit in is actually the real benefit from doing it.
Charles Humble 00:40:36 That said, I also want to say you don’t have to do this. You know, contributing code to an open-source project is time consuming. You are effectively doing work for three. I think it’s a good thing to do, but I absolutely don’t think if you’ve got other pools on your time, I don’t know, maybe you’ve got young children or old parents or something that you have to look after. If you’ve got other demands on your time that mean you can’t do this, that should be understood too. It’s okay. But I do think it’s helpful and as I say, I do think it’s particularly helpful when you start out because it exposes you to a bunch of stuff that you won’t learn as quickly any other way, I think is the best way I can put it.
Brijesh Ammanath 00:41:13 What are some best practices to get started with open-source contributions?
Charles Humble 00:41:17 There are lots of different ways to do it, but I think one of the things to do is to try and start by choosing a project that you use regularly and ideally with a bug or something that you actually want to try and fix. Keep in mind that it’s very easy as a programmer to think the only can contribute is code, but depending on what your strengths and weaknesses are, that might not be true. So you could think about, might I start on the documentation? Most open-source projects suffer from poor documentation, a lack of documentation. That can be a good place to start. If you’re good at UX, think about whether the UX might require some help. If you speak multiple languages, maybe you can translate stuff from one language to another. Things like accessibility, graphic design, organizing, meetups, all those things are important.
Charles Humble 00:42:01 If you’re thinking about the project itself, specifically thinking about contributing to the project, there are going to be a bunch of files that you need to read before you start. So they’ll typically be a read me, they’ll typically be a license. There’ll typically be a file called something like contributing or contributors, which sets out how the project likes to receive contributions. There should also be a code of conduct and the code of conduct will set out the behavior that’s welcome, the consequences for unwelcome behavior, all of that sort of thing. My personal take is I am very reluctant to get involved in any project that doesn’t have a code of conduct. Obviously, that’s up to you, your mileage made vary and all that, but if it does have a code of conduct, absolutely make a point of reading it. The project will also have an issue tracker, so that should allow you to find what some of the issues are.
Charles Humble 00:42:49 And some projects have like a good first issue tagged or something like that. So that can be a good easy sort of entry point. Otherwise, if that’s not the case, look for the smallest and easiest contribution you can make. So A, you can build up confidence and B, you can kind of establish a bit of a relationship with the maintainers on the project. The other sort of plea I would make is always keep in mind that being an open-source maintainer can be thankless. You get lots of stuff, some of it’s very well intentioned, some of it less so. So always bear in mind, open-source maintainers are busy people, they’ve got a lot of difficulty, you know, a lot of challenges on their time. Again, it sort of comes back to what we were talking about with terms of empathy. Try and imagine if I was the maintainer on this project, what are the things that I would like to see in order to be able to do whatever, merge this in. So yeah, I think those are probably the main ones main. So think about how you’re going to contribute, the right way to contribute, whether that’s coding or UX or documentation or whatever. Make sure you read the foundational files, the read the license, the contributing file, the code of conduct, and then look for like a small thing to start on. So like a good first bug or a minor contribution you can make to get going.
Brijesh Ammanath 00:44:06 I like your tip about using documentation as an entry point to get involved in open-source projects. Not many people are very enthusiastic about writing documentation, so this could provide the path of least resistance to get involved in open-source projects. That provides us a good segue into the next theme of shortcuts, which is around documentation skills. What are some common mistakes engineers make when creating documentation and how can they be avoided?
Charles Humble 00:44:35 Oh, again, that’s a great question. It’s quite a broad question to answer. I think one of the mistakes that people often make is they don’t think about who they’re writing for. So the very first thing to do is to start by scoping out. We typically call it a persona in writing, but that’s maybe a little bit of a funny term to use. Basically what you want to do is start by identifying who your audience is. So knowing who you are writing for will help you write in a way that’s appropriate for your readership. So most technology websites, most marketing departments will develop these things called personas, which describe the audience. You can kind of do the same thing. So a persona might consist of a job title, like junior programmers say, an objective like learning how to use the API and a set of assumptions that you’ll making about this person.
Charles Humble 00:45:26 So I think my person is going to be familiar with Go, I think they’re going to be comfortable following a set of command line extractions. I think they’re going to have a laptop that’s either running Windows or Macs and has downloaded the SDK already. Once you’ve got that in your head, that then helps you to think about, well what does that person need to know? And then the other trick is always, always favor the reader. So with that set of assumptions, it’s a really good idea to let them know upfront what assumptions you’re making and to provide links to the other resources so they can learn from those. I would also recommend defining what’s in scope for this particular document and what it isn’t. So you know, this is what this document describes in detail. The API for our thing, it does not describe the underlying architecture and the underlying architecture is described in the architecture guide, which you can find here.
Charles Humble 00:46:17 Defining scope and non-scopes really helpful because it allows you, as a writer, it helps you stay on topic, but it’s also helpful for the reader because the reader knows what to expect when they’re reading your thing. So that’s the place I would start. Other common problems are things like using terminology inconsistently or making assumptions that everyone knows this terms, I won’t explain it. If in doubt always, if you’re using something like an acronym, always spell the acronym out first. You don’t need to do that for something like RAM or ROM or HTML or whatever maybe. But if you are not a hundred percent sure that your audience is going to know it, explain what you mean. Be very, very careful about using terms consistently. So, if you are referring to something that’s protocol buffers don’t suddenly change to calling it protos partway through a paragraph because some of your readers won’t understand that those two terms are interchangeable.
Charles Humble 00:47:08 So that’s another common one. As an industry, we’re very fond of three letter acronyms, TLAs, and your point with documentation is to convey meaning. So if you are overusing acronyms, you can end up making your document really hard to read. You just end up with effectively like a, it looks like a bowl of alphabet soup or something. So in that situation, go back and spell the abbreviations out in full, watch out for consistency and try and be as clear and concise as you possibly can be. And that takes work. So I reference a book quite a lot called On Writing well, which is by somebody called William Za and he has this wonderful phrase, he says, the secret of good writing is to strip your sentence to its cleanest components. And basically your goal should be to get to having the cleanest, clearest sentence that you can.
Charles Humble 00:47:58 So in the same way that when you are coding, you want your code, your methods, and your functions to be as clearly defined as you can manage and as easy to follow as you can manage, you want your sentences and your paragraphs to work the same way. The other thing which I think people often miss about writing is it’s actually a visual medium. So people will see the text on the page before they read any of it. And what that means is things like lengths of paragraph matters. So if you have very, very long paragraphs, particularly at the beginning of something that can feel a little bit intimidating. Conversely, if you have lots of one sentence paragraphs, that can be a bit off-putting as well, two or three sentences probably about optimal. Funnily enough, it varies a bit. So written text is different from online. With written text you can get away with slightly longer paragraphs than you can with online text. But yeah, a lot of it is thinking about consistency, thinking about conciseness, and trying to be as clear as you can possibly be and knowing who your audience is upfront.
Brijesh Ammanath 00:49:04 I think quite a few of these steps are also useful in making effective presentations.
Charles Humble 00:49:09 There are strong parallels between the two things, I think. So yes, I have a whole section on presentations and the business of writing a good presentation and so on. And I sat down and chatted to both Holly Cunnings and Tricia Gee, who are both very experienced conference speakers as well. But yeah, it’s absolutely the same thing. The thing with a presentation, you can have a brilliant presentation, but if you are giving it to the wrong audience, it’ll be a bad presentation, right? It won’t land because the audience either it’s too basic for them or it’s completely going over the top of their heads and they’ve got no idea what you’re talking about. So absolutely understanding who the audience is, is really important. At the very least, you’re going to want to know who they are likely to be. So am I looking, speaking to a bunch of hands-on developers, am I speaking to a bunch of technical leaders, tech decision makers, how much experience are they?
Charles Humble 00:50:01 All of those sorts of things. You know, are the developers at the conference more kind of full stack or do they bias us towards backend development or front-end development? Is this a monotech audience, like everybody is a Java programmer or is it a more general sort of architecture cloud conference? All of those kinds of things matter because it lets you know what to pitch and what you’re going to explain and what you don’t need to explain. And yet I think in general, understanding the audience is the absolute key thing really. And then other than that, again, there are quite strong parallels. So the different media have different aspects about them. So whether that’s podcasting or writing or presenting or making videos on YouTube or whatever it is, there are obviously sort of media specific aspects to them, but there are a lot of commonalities. So if you’ve learned one thing, if you’ve learned to write a blog well, but actually you’ll find a lot of those skills are applicable to presenting as well.
Brijesh Ammanath 00:50:56 We have covered a lot of ground over here. We have touched on all the four themes. Before we close the session, I would like you to expand on the single most valuable thing you have learned in your career. You touch on this in the final section of your shortcuts.
Charles Humble 00:51:10 I think this is what you’re asking about. There’s a final piece of advice I give and it’s a piece of advice that I got from my lovely mother. And my lovely mother knows nothing about computers. I don’t think she’d mind me saying that. She is very, very, very good at people. And when I was younger, I found that baffling, because I wasn’t very good at people. And I sort of asked her about it and she gave me various bits of advice. But the most useful bit of advice she gave me was that most people are glad to help you provided you’re polite when you ask. And at one level that sounds sort of a bit trite and a bit obvious, and I certainly wasn’t very impressed about it when she first told me it. But I have to say that as I’ve got older, I’ve realized what an incredibly astute piece of advice that is.
Charles Humble 00:51:58 So for me personally, the first time I did it was about 30 years ago, I was working in an investment bank, and I was automating some stuff in Excel, in Excel.5, I think, using VBA visual basic. And we couldn’t get Excel to do what we wanted. And I ended up reaching out to a guy called Eric Wells, and he wrote a book called Developing Microsoft Excel Solutions. And I reached out to him, he was a Product Manager at Microsoft at the time, and said, we’re having this problem, can you help us? And he sent me an email back about a week later with an explanation that not only explained how to solve the problem, but every related problem you could think of. And it was a very charming email. And since then I’ve been regularly quite astonished at how kind and generous people are. So industry leaders in our industry, the sort of thought workers type people, how kind and generous they will be with their time, and how willing they are to share their knowledge.
Charles Humble 00:52:54 Basically, if you ask nicely at the end of the day, why wouldn’t they be? We’re all learning, we’re all trying to improve. This is a knowledge industry. And what that means is basically we’re all learning all the time. So if there’s someone whose opinion you would value, reach out to them, send them an email or a message on LinkedIn or Mastedon or whatever it is you choose. And it’s entirely possible that they won’t reply. But in my experience, most people will be more than happy to help you if they possibly can. And the sort of flip side of that is you should do the same thing. So I have a thing that I say a lot, I’ve said it many, many times, which is that as an industry, we are at our best when we share our knowledge. And that’s basically how we drive our industry forward, is we share what we know with each other.
Charles Humble 00:53:39 And so if there’s stuff that you know, think about how you can share that, whether that’s speaking at a conference or writing a blog or whatever it is. Doesn’t really matter how you go about it but share that knowledge and pass it on. And yeah, absolutely seek out people whose opinions you would value and ask them, you know, have you got five minutes? I want to talk something through. Obviously, it’s easier if you’ve known someone. If you go to conferences and you meet people, that can be helpful. But even if not, you know, people email me regularly and as far as I possibly can, I always try and make time and most people I know are the same. So yeah, reaching out is a good and underrated thing.
Brijesh Ammanath 00:54:17 That’s a gem of an advice. And if there’s one thing that you take away from the session, it’ll be this last piece of advice, which is, if you need help, don’t hesitate to reach out and ask for it. Most people in our industry will be more than happy to help you. And with that, we come to an end to the session. This is Brijesh Ammanath for Software Engineering Radio.
[End of Audio]
