Balancing Teaching and Technology with Ken Kousen – Techstrong Unplugged EP8
Ken Kousen, a seasoned software developer, educator, and author of six books, shares insights from his nearly 20 years of experience in technical training and his role as a professor at Trinity College. He discusses his approach to education, emphasizing the importance of hands-on experience, test-driven development, and engaging with open-source projects. Ken also explores the challenges of teaching in a male-dominated field, the significance of supporting underrepresented communities in tech, and the evolving landscape of AI and its impact on beginner developers.
Transcript
Hey everybody and welcome back to Textron Unplugged. This is episode eight of our series, and I'm your host, Daan Solo. On Textron Unplugged.
We dive into all things tech and get people up to speed with everything happening across the industry. Recently, our co-host, Cassandra Chen, went to the Great International Developer Summit, also known as gis 2024 at GIS 2024, Cassandra sat down with Ken Cozen, who is a seasoned software developer, educator, and author of six books. Ken dives into his approach to education and he emphasizes the importance of hands-on experience test-driven development, and engaging with open source projects.
Ken also explores the challenges of teaching in a male-dominated field and the significance of supporting underrepresented communities in tech. Finally, Penn and Cassandra touch on the evolving landscape of AI and its impact on beginning developers. Without further ado, let's head over to GID 2024.
Welcome back to Text on Unplugged. I'm your host, Cassandra Chin, and today we have Ken with us here today. Do a brief introduction.
Oh, you want me to do it? Yeah. Uh, okay.
I'm a one person company software developer. I mostly teach technical training classes. I've been doing that for about, actually almost 20 years, uh, as a on my own.
But, uh, I also teach in academic circles. I'm a professor at Trinity College in Hartford, and I've been the speaker and author of, uh, six different books now, working on a seven. Anything else you wanna know?
That's a lot of books you've written before. Well, just to tell you, I didn't write my first book until I was actually 50 years old, so it's never too late. You know, don't, don't think you, if you don't get it early, you, you're, you're, you still have an opportunity to do it.
The, uh, economics of technical book writing. By the way, if you were to buy one of my books, I can buy a cup of coffee, but not at Starbucks. Not at Starbucks Finance.
No. Are you sure it's even a cup of coffee? Probably not, but I could get it somewhere, you know.
Do you wanna talk a little bit about your values on education and, Well, my whole career since I've moved to it has been based on the idea of teaching training classes and passing on what I've learned to other people. In fact, it was, it's kind of a, a, a personal mission statement, I guess, is that I really like learning new things. I like working with it.
I don't feel I have to be the person to invent it. I just wanna learn what's been done and what the cool new toys are, and then tell everybody about it, passing that on to others so that they can take advantage of what I've learned. So that to me is fun, you know, to experiment with the new toys and then say, Hey, look at what you could do with this.
So look what you could do with that. So that's really behind a lot of the speaking and the writing and the blog of the newsletter or the, the YouTube channel, all of it. So you don't feel like you always have to be the one to create that technology yourself.
I actually don't even really enjoy that as much. I mean, I did that, I was a research scientist prior to being a developer and, you know, all the easy problems have been solved, you know, so you're always working really hard and, and you always had to get funding and things like that. I never liked begging for money.
No. It's more like I liked learning and therefore I would like in the groovy community, I used to make friends with the core team members and then see what they did and go, oh, cool. Then I get to play with it.
It's like they're making the toys I get to get to play with and the Java world is like that now that I enjoy that much more than making the actual toys. I like playing with the toys. How do you balance like showing off the toys because you're not the one made who made it, so you can't take credit for it.
Yeah, right. No, I mean, I do have to, well, I, first of all, to figure out how to work with them. I do tend to focus on the test cases as the, the better the developer, the more tests they write.
And the high qu the high quality test will show you how the developer intended for the toy to be used. You know, it'll give you the sense of it. The release notes will explain what they were after.
So I'm mostly focused on what we actually have, the documentation, the test, and if I still get stuck and I don't know what to do, most of them are more than happy to share that information. Just contact 'em and say, Hey, I'm writing this up. I want to advertise.
It's a way of participating in open source as someone supporting the developers without competing with them. I mean, I'm not unhappy that they did it and I didn't. I just, how did you, what did this mean?
What was that for? How do we use that? You know, they generally welcome questions like that as long as it's not.
Yeah, I don't know how we do that. Have you ever heard of the saying like, test twice, code once? Um, it's an old cliche, right?
And it's based on measure twice. Yeah. Once on, on manufacturing.
I don't know. I, I am not great at doing pure test driven development. I do agree that you never trust the test, you haven't seen fail.
You have to see it fail otherwise, you know, you could wind up with one that that passes all the time, doesn't test anything. But I tend to follow, instead of pure TDD, I tend to follow what I call GDD. So instead of tests for development, I do what's called guild driven development.
If I write code that hadn't been tested, I'm worried about it. I feel guilty until I put a test. I really like that saying You're feel free to take advantage.
Guilt Driven development. Yeah, I mean, I like J Unit of course. I like, uh, cert JI think that's a really good testing library.
I like property based testing with Jake quick as a way to find out the boundaries of what works and what doesn't. So, uh, I'm a big fan of that. I, I use tests and spring framework tests all the time.
Um, I, testing to me is like otherwise I just am worried that I'm wrong. I mean, how do you know you're right unless you have a test to show it. I think that's really great to value testing.
I'm glad, I mean, I, I never understood developers who say they didn't want to test. I feel I code a lot faster if I have the test. And of course now with the AI tools, they can write a lot of the tests for you.
You just have to check and make sure that what they're generating is makes sense. But that speeds up the process, you know? And that also gives you the, the confidence and the freedom to refactor you.
You have to be careful that the tests don't over specify how things are done, that they're just testing what to do. 'cause if they overs specify the how, then you're locked into a particular implementation. You don't want that.
You just wanna test a high level use cases. What is this supposed to do? And I go from there.
I, I wrote one of my books is on the ma keto testing framework. You know, how do we work use ma keto? And I think I'm doing a talk on that on Friday on uh, how to use that to mocks, make mocks and stubs and spies for your classes.
You mentioned how like you're at this stage in your career where you wanna really pass on your knowledge to the younger generation. Absolutely. I, I think that's really important, especially because the AI tools are going to possibly be a threat to a lot of the beginner developer jobs because the AI tools can do a lot of routine stuff.
Well, and a lot of early developers in their career learned how to do these things on the jobs that were fairly routine. It's important that I try to make sure they know how to do these tools. Um, I do enjoy teaching the more advanced classes, frankly, I got tired.
I get tired of teaching intro Java again. You know. But in general, it's, I'm at the stage in my career where, I mean, I've kind of achieved everything I was looking for.
I've been very fortunate. Um, but it's time to pass that on to the next generation. And especially for, well women and underrepresented minorities, you know, people who have not had the same opportunities.
I at least have benefited from that. You know, I an old white male, you know, what are they gonna do that I'm not? The barrier I encounter, by the way is age issues because this is a very young community, right?
Yeah. And if the average age of developers is like the late twenties, early thirties, and I walk in there, they people worry that, oh, is this a curmudgeon? Is just gonna say, oh, it was so much better back in my day and all this new stuff is awful.
And I don't know, I have to convince them that I have something to contribute, but that takes me five, 10 minutes I can get there. Whereas I don't have the actual disadvantage that a woman or an underrepresented minority might have to overcome just to be heard. I figure if I can help them get an opportunity, if I can give them the information they need, you know, tell them what things are actually like out there.
Maybe even make introductions and stuff like that. Bill help you build your network. Yeah, I really like that.
I'm glad 'cause I don't wanna take all these other jobs. I want to help somebody else get 'em. How do you actually reach these underrepresented communities?
That is actually tough because we are a very diverse crowd internationally, but not, I mean, we're very male dominated as you know, you know, it's kinda ridiculous. So what I do is I try to seek out speakers and things at conferences like this who are women or underrepresented and make sure I pay attention. I mean, frankly, sometimes all you have to do is listen, you know, and not talk down to them and not, not be, uh, difficult or anything.
And that's enough. You know? And that's all they need is some validation and possibly help getting an opportunity.
But mostly just basic respect. And it goes, it works wonders. I mean, because they're so happy to get it.
You know? So, so I think for you that would be like striking up a conversation with them. Yeah, Absolutely.
And you know, go to a talk and then after the talk tell 'em you thought that I did a great job or what you liked about, uh, the other thing I've noticed, of course I have several friends who are, you know, in, in those categories and like, uh, Tricia G for example, I don't know if you know Trisha. Yeah, I think I know her. Yeah, she's out outstanding, you know, Java champion and everything.
I think she works for Gradle these days. Any rate, she doesn't like getting invited to conferences to talk about women's issues again, you know? So I make sure when I talk to her to focus on technical problems that I know she has an expertise on it.
She also is really good at the soft skills too. So I ask her about that stuff and I try to say, if you want to talk about women's issues, we could talk about women's issues. But if you're tired of all that, we could do something else.
I'm some speaker friends who are women and they say they're tired of talking on woman being the only woman on panels. I know. And it's just, I mean, there is a number problem.
And some of that does in fact come from the pipeline that there aren't enough women and underrepresented minorities in the pipeline. But a lot more of the problem is the attrition rate is how many women leave the field within the first five years. And underrepresented minorities too.
Any woman I know who's been in it for more than five years, I automatically have respect for, it's hard to be in a male dominated field anyway. And there's a lot of what I call boys behaving badly out there. Yeah.
I try to step up and stop that When you first get into your career as a woman, uhhuh, it might even take five years for someone to suggest you come to a conference and when you go to a conference, you meet cool people like you, who really give women respect. But until you actually go to a conference, like you're in your little bubble of guys working together. And that's a challenge.
It's true. I mean, it's hard for everybody to break outside their bubble, uh, always. But women have certain advantages in that the numbers are small and therefore conference organizers are looking for them.
It, it's really partly it. Um, it's the classic problem they say of men will often apply for jobs when they don't have the skills and women won't. And when what you need is you need allies, you need more senior people, men, women, or anybody who can encourage you and say, you know what, throw in a a proposal.
You know, if you go, you go. If you don't go, okay, fine, you haven't lost anything. And you also start making contacts.
'cause a lot of the conferences look for people they know and have done these things before. So that initial breakthrough that you're talking about, that is an issue for everybody. It may very well be harder for women.
I, again, you'd know better than I would on that, but you, you solve it the same way you solve anything else. You build your network, you establish your, your, uh, reputation. I mean, I got on a speaker tour when I wrote my first book and I had to keep bugging the organizer for March to let me on the tour.
So you never know. So I think we definitely need more great allies like you. Oh, well I appreciate that.
I do what I can. I don't know how much I can do, but I can provide some emotional support and well, You're here with me today, so. Yeah.
Yeah. I appreciate it. Well, I'm glad to do that.
And as I say, also, I'm joining the, the faculty at Trinity College full time. So I'll be teaching a lot of undergrads. And what I try to do in my class is to say, look, I, we're not, let's not worry about what's in the textbook.
This is what's going on in the community right now, you know, so, uh, news item will come up, like, red is changing its license, you know, or that, that XZ problem that provide a backdoor into the, into the secure sockets and everything. We use that as a case study and we talk about it, you know, what's happening in the community. So you just put that textbook aside.
Yeah, I mean, I, I'd rather do the more senior level classes so that it's not just canned material, but that way we could say, you know, oh, and by the way, I know this is what the book says, but it is one of the few areas where the working professionals are ahead of the academics, with certain exceptions of course. But when I was in engineering, the academics were ahead, you know, 'cause the people have been building bridges for thousands of years. But it stuff, it's the people in the community who are doing the innovative stuff and learning things all the time.
And that's what I feel like I can bring in and say to the students, Hey, you know, let's get involved in an open source project. Let's see what they're doing. Right.
Test cases, see what the best developers do. Honestly, I think that's the best advice you can give. Asking them to get on an open source project while they're still in school.
Yeah. You just have to be careful because just like anything, there's good and there's bad. So it's part of the challenge is assessing which ones are worth your time and which ones are worth your energy.
Find the right community. That's actually more important than the actual library you're working on. You know, you find the right group of people and it's a really enjoyable experience.
You find the wrong, wrong group of people. You don't wanna do it at all anymore. I hear a lot of advice, which just the advice is join an open source project and get involved, but you really break it down like it's people behind the projects.
Well, the only, yeah, and the difficulty again is that a lot of open source people, they welcome people joining the team, but not if they're just gonna be there for a semester. You know what I mean? They want to form a longer term relationship and they don't want to have to teach the very basics of all the tools.
So there is a startup cost. You have to learn how to do issues and get, and, and merges and call requests. And you have to learn how to write test cases and learn what the, what the deployment processes are.
You know, there's a lot to learn. But if you can find the right team that's willing to accept newcomers, then yes, it'll put you an enormous advantage. Because even if when you go interviewing as a young student to get a job, companies will look and say, well, what have you done?
You say, well, I contributed to open source. They may not even care what the project is. The fact that you did something that's real world matters, you know, that really helps.
Yeah. So in your classes, are you teaching like the startup cost? Like you're getting lis and know how to use the tools?
Um, We try. I mean, we do have spend time on Git for example, because everything's using a Git repository somewhere. Uh, we talk about, you know, how you raise issues and, and how you write test cases and what's a normal agile process.
You know, how do they, what's the difference between committers and contributors? And you can just write documentation and you're a contributor. You know what I mean?
Yeah. 'cause they think, well, if I don't write code, I'm not really contributing. Heck, I suffer from that.
I have one commit to the groovy code base, and I wrote a whole book. And then yet they, the, the people, the committers say, no, no, no, you're a contributor. And I'm like, but all I did was one commit, you know?
But it doesn't matter. So yeah, we try to do that as much as we can. Okay.
I think we had a really good chat today. Ah, Yes. Absolutely.
So thank you Ken, And good luck with the other interviews or whatever you're doing. And whatever you're using this for, uh, let me know if it goes live. It will definitely go live on Textron tv.
Textron tv. Great. Well thank you very much.
