Programming is fun

If you’re doing it right, that is

I recently had the privilege of being a guest on the Cup o’ Go podcast, where I chatted with hosts Jonathan Hall and Shay Nehmad about teaching and learning Go. You can listen to the full interview here: Cup o’ Go #21: John Arundel interview

Here’s a lightly-edited transcript of the discussion.

So John, tell us a little bit about who you are and what you do.

I’m John Arundel, I’m a writer of books, including Go books, and I also teach Go. I also write Go programs, but I don’t get paid (as much) for that.

You said that you teach Go—do you do that online, or in person, self-paced courses—how do you teach Go?

Yes, private lessons online, and I also have a course.

Do you also work with companies? Like, say I want to take my R&D group, and move them from Python to Go?

Yes, absolutely. I’d be all over that. Just get in touch.

Nice. I wanted to ask you about the name of your site, Bitfield Consulting? That’s a really good name. What’s the story behind it?

I could have used my own name, but that would be kind of boring. I wanted a computery word, but that also sounds like it could be someone’s name. Like, there could be a Mr Bitfield. I mean, that would be a neat name for a technology consultant.

You have a ton of really cool icons. Who’s doing the art?

There’s a really nice repo of free Gopher clip art by an artist called Maria Letta: lots of high-res PNG images and SVGs.

I’m very keen on them, and they make me look great, even though I had no input into the design.

It does fit the idea that I’d like to put across, that some of this material may be a little bit dry, but we can try and make it fun. That’s the best way to learn, isn’t it, when stuff is interesting and fun.

What’s it like teaching Go? Let’s say I want to learn Go; most people who come to you are not complete juniors, right? They already have experience in software development?

It’s a mix. Some people have lots of experience in other languages, but just not in Go; some have lots of experience in Go, but they still feel like there’s more to learn (I’m sure we all feel like that).

Other people have no experience of any kind of programming at all, but think it sounds fun and want to try it—I like teaching those people the best!

We’ve talked a lot about whether Go should be the first language someone learns, or always the second language. What’s your opinion?

I like the implication of the question, that whether or not Go is the first language you learn, it shouldn’t be the last! There is a lot of value in knowing more than one language.

But while it’s nice to have some exposure to lots of popular languages, it’s also worth diving deep into one or two if you can. It’s only when you get to know a language really well that you experience a kind of breakthrough, and you can really do good stuff with it.

It’s also very circumstantial, right? Like if you have a friend who happens to know, say Python, or PHP, really well, they can help you.

Exactly. And it’s also about what kind of mind you have, isn’t it? Some languages are better suited to certain minds than others.

I know people who are highly intelligent, but for whatever reason Go doesn’t seem to suit them—doesn’t think the way they do. So they’re not productive with it, and that’s fine: they should use the language they like.

Go definitely needs to click with you.

That’s right. Most people’s first impression of Go is probably not that favourable. When I first looked at some code I thought, “Oh, that’s ugly! I don’t like that!”

Which is weird, because I like C, and it looks a lot like C. And I think that was my problem initially, because in the days since I was a C programmer I’ve had affairs with Ruby, and Python, and other beautiful languages.

There’s something gorgeous about Ruby in that you can shape it to be almost whatever language you want. Whatever way of writing programs appeals to you—object-oriented, imperative, functional—you can do it in Ruby. It’s so protean, you can do anything.

Go is definitely not like that, I think we can all agree. It’s very opinionated. But the thing is it has all the right opinions!

Go maybe isn’t as attractive as some other options at first, because the language is very lean, it’s very simple. By comparison if you’re learning React or Next.js, it feels like you’re getting a lot done really fast.

Very true. And when I’ve been training corporate teams sometimes I’ve gone around the room and asked “Why do you want to learn Go?” And the answer is “I don’t.”

And it turns out the company has just told them “We’re moving to Go, so learn it or ship out.” That’s a shame, because maybe if they’d come to Go through another route, they might quite enjoy it, but no one likes having a new language forced on them.

I’m not sure if Go really makes a good first language to learn. It’s a tough language to teach! There are some really brain-bustingly puzzling things about it. I ask new students what they’re least confident about in Go, and you can probably guess the kind of things that come up: pointers, concurrency, even things like structs and methods.

These things are fundamental to Go, but if you’re not used to programming with them, it’s really hard. It’s tough to put yourself in the mindset of someone who doesn’t know that stuff—but that’s what teaching is.

I’m curious: how did you get introduced to Go, and how long ago was that?

I’ve been programming basically forever, and used a lot of different languages. When Go was announced, I looked at it, thought “That looks ugly, and it’s from Google. No thanks.” Clearly that was the wrong take!

A few years ago I was consulting with a company that was in the process of switching their development to Go, and I thought I’d better learn something about it, or there was a danger that I might become irrelevant.

Consultants are good at mugging stuff up really quickly and then sounding authoritative about them, but I had a really hard time getting to grips with Go at first—perhaps most people find the same.

I came from Perl primarily, and so I was using interface{} everywhere, because I didn’t know how to think in the Go way. In Perl, everything’s dynamically typed. And then trying to wrap my head around the idea of composition…

I think maybe it’s a big advantage in some ways if you’re not a computer science professor and you don’t know all about the history of programming language design. Because if you did, you’d be upset with Go, thinking “Where is everything?”, right? “Where’s all the good stuff we’ve been writing papers about for the last thirty years? They seem to have just left it out. Maybe they didn’t read the literature.”

I highly doubt they didn’t.

They did read it, and they didn’t like it. They said “We’re not having that!”

You said that you used to be a consultant. Is teaching and writing about Go your full-time job at this point?

Yes. The part of consulting that I always enjoyed the most was teaching people how to fix stuff themselves. I mean, I can parachute in and fix their server, but the more interesting thing for me is “How do I make it so that they don’t need to call me back next time it crashes? How can I help them build a self-healing system so they don’t need a consultant anymore?”

That maybe explains why I wasn’t a great success as a consultant, because I never got any repeat business! I still consult occasionally on interesting projects or problems, but the really fun bit for me was always showing people neat stuff like Go, and seeing the lightbulb go on over their heads as they realise what they can do with it.

I love that part, and at a certain point I decided I want to focus on just that.

And it’s working well for you.

I still really enjoy it. It’s so much fun. I realised after a while there’s only one of me, and I can’t teach everybody, so if I want to reach more people, I’d better write a book. So that’s why I did that.

And now you have many of them!

Right. And it works really well with the mentoring, because you need to find the right word or phrase to unlock a certain idea. And for each individual person it could be different. You probably need to try a few different ways. I mean, I’ve tried a zillion different ways of explaining pointers, and I still don’t think I explain it very well, but I’m getting there.

Working with students helps me refine that stuff: I see what works and what doesn’t work, and what’s the right order to introduce different concepts that depend on each other. And then that can go in the book, and make me look like I just got it right first time.

And in the process of writing a book, you don’t want to look like an idiot: you do your research, you read up on the stuff, and check the facts. And I learn a ton of stuff that way!

That’s one of the reasons we started this podcast: to help us keep up to date on what’s happening with Go. We had another author on the show, Adelina Simion; she wrote Test-Driven Development in Go. And she said exactly the same: she learned so much about testing through writing the book.

That’s right. The best way to learn is to teach!

You often say that programming is fun, and that people should have fun. While I totally agree with you, in big organisations, for example, that’s often not the focus point. Why is it so important for you?

Well, I know it sounds like one of these “motherhood and apple pie” things; who doesn’t think programming is fun? But unfortunately a lot of working programmers don’t feel that way.

When I was a little kid I would play around writing programs in BASIC and so on, and thankfully it’s never stopped being fun for me. But a lot of people see it as a lucrative career and they go into it for the money or the security or whatever. And it’s not a whole lot of fun for them. I think that’s a shame. If they can find a way to make it fun, it’s a more enjoyable career.

Also, I’ve noticed the students who make the quickest progress, and become the best software engineers, are the ones who are having fun. The more fun they have, the more programs they write, and the better they get at it. If something’s not fun, you’re not going to do it.

Totally.

So it’s worth reminding people “Hey, it’s nice to get a check, but we’re basically doing this because it’s enjoyable.” And if not, that’s a real shame, because you’re going to spend your life doing this stuff!

Perhaps some people are thinking “But it’s not always fun. What if you have some horrendous codebase with no tests, and you have to fix something—how are you going to make that fun?”

My answer to that is, “You make a good point, imaginary interlocutor, but how did we get into this situation in the first place?” And often the reason we’re in a no-fun situation is because we don’t have tests, and often the reason for that is that we don’t really have a clear idea of what the program is supposed to do.

I think a big part of having fun when programming is enjoying your profession, feeling smart, solving problems, being proud of what you build. And it’s something that gets lost when you work in a super large company and ship to deadlines and so on.

That’s so true. I mean, we’re all working within constraints, but if the attitude is “I’m doing a fun creative thing, this is enjoyable and I’m good at it,” you can have fun, within those constraints.

You can still do a good job even if you’re being rushed or pressured or stressed. You can say “Let’s push back on that a little and ask, given the time, scope, etc that I have, what’s the best job I can do?”

What advice would you have for somebody who’s trying Go, but may be struggling with it? How can they get over that hump?

The best way to learn is by writing some programs, and the best way to do that is to have some program that you want, or that you’re interested in. Maybe it’s some subject area that interests you, like cryptography, or networking, or databases, but you can think of something that you could write in that space.

The ideal thing is if it’s some program that you actually need in your daily life. Then it’s not an exercise. It’s not like a musician practising scales: that’s helpful, but you also need to play music. In fact, that’s the best way.

Content creation is also a great way to learn. Just start writing blog posts about the libraries you’ve learned, follow up on some links, talk to people, and share the content you create with others.

Exactly, that’s great advice. And please don’t wait until you feel like you’re an expert in the subject before you’re allowed to blog about it. I certainly haven’t.

Please learn in public, because that’s the most valuable kind of content for learners: to see what problems other people found difficult, and how they solved them.

And I’ve often found, when pairing with students, it’s great for them to see me making a ton of mistakes: I forget things in the standard library, I get compile errors and typos. I think they see that and feel a bit more relaxed. “Hey, that guy knows what he’s doing, and he’s making mistakes, too! I’m operating at the same level as he is!” That’s terrific.

Let’s say you had to remove a feature from Go. What would it be?

I could probably dispense with quite a few things in Go! Mat Ryer did a great talk called Things I Never Use in Go, and among those were at least four of the keywords, plus a few other things.

I’ve found from experience that if you try to teach people everything, they can’t take it in. It’s too much. So I politely don’t mention a few things which, in practice, they won’t really need to know about: complex number types, for example (unless you’re a physicist).

Needless to say, I don’t use goto. Though if you read the standard library code or the Go runtime (I recommend this as a fun recreation), you sometimes see it used, and I guess with good reason. But for all normal purposes, we probably shouldn’t have goto, just in case someone uses it.

Something that causes a lot of confusion is the short declaration form, or “walrus operator” (:=). Even the Go designers have said that was probably a mistake, because you can get shadowing, or it’s not clear which of two variables is being implicitly declared.

Something that seems like a free extra bonus feature introduces confusion, because now there’s two ways to do it: should I use var, or :=? And any time you get some really weird bug in your program, it’s probably something to do with accidentally shadowing a variable.

But you can make too much of this kind of thing. I mean, you can say “There’s a construct in Go that allows you to write bad programs.” Shock horror! Thank goodness no other languages have those, right?

If you could cop a feature from a different language and put it into Go, what would it be?

I definitely think there’s scope for multiple languages, as we said at the beginning. Some languages have the philosophy of “Let’s put everything in, and then people can just use the bits they like”—C++, for example.

But there’s a small group of languages, and Go is one of them, where the designers clearly felt “Let’s take away everything we can, until there’s just enough left to be able to write useful programs, and if you need certain constructs, you can build them yourself.” LISP is the ultimate expression of this: there’s practically nothing there but brackets, eval, and apply!

Go clearly started with C and took out the bad bits, and I love that. I think that mindset carries over into our Go programs as well. It’s like the language is telling you “I’m really minimalist! Shouldn’t your programs be the same?”

So I love the fact that Go hasn’t felt the need to include every neat idea from every other language. They stole many excellent ideas, of course, but they stole just the right ones, with very good taste.

I genuinely don’t think there’s anything I would want to add to Go. I’m sure I’m in a minority here, but every time the survey comes round asking what’s missing from Go, I can’t think of anything! I seem to be able to get by with Go just fine as it is.

[By the way, the Go team were so perplexed by this that they reached out to me for a call to discuss it. We had a nice conversation, but I think they’re still a bit confused by the idea that someone might like Go just the way it is. They’re probably not used to that.]

Even generics—I was like “Sounds great… I never felt the lack of them, but now they’re here, let’s use them to build neat stuff!”

Well, John, it’s been a pleasure. I read your book several months ago, and it’s nice to finally meet you. Thanks for coming on.

Thanks so much for having me.