PostHole
Compose
Login
SE Radio 655: Charles Humble on Professional Skills for Software Engineers
In this episode, Charles Humble speaks withhost 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 former 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.
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
Other References
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.
[...]