RWDevCon 2017 Inspiration Talk: I’m an Idiot by Richard Turton

Rich is a professional idiot. In this talk from RWDevCon 2017, he talks about how to leverage your inner idiot to make you a better coder, writer and communicator. By Richard Turton.

Leave a rating/review
Save for later
Share
You are currently viewing page 2 of 4 of this article. Click here to view the first page.

Step 2: We’re All Idiots

Hopefully I’ve established my first point that I am an idiot. This is the slightly harder part of the talk: I have to convince you that maybe you’re an idiot. The way I’m going to do this is show you some quotes I’ve collected some quotes from people I’ve lumped together under the term “high-performing idiots”.

I’m hoping some of these quotes will resonate with you and you’ll think, “Oh yeah, I’ve been like that. I’ve been in that situation.” And then maybe you’re going to start to think you’re an idiot as well.

We’ve all had that moment where you’ve been trying to do something all day and it’s just not been working, not been working, not been working. And then suddenly a light goes on, and you’re a genius! You’ve made this thing, and it’s amazing! That transition, that feeling … It’s probably the main reason I do this job, actually; I love it. The transition back from the genius state to the idiot state is not so enjoyable, but I think it was William Shakespeare who said, “Life is a rollercoaster, you’ve just gotta ride it.”

Billy Shakespeare totally possibly might have said this. (image via Pixabay.com)

Onward. :]

This is from Alexis. If you were in Alexis’ talk this morning, you’re thinking, “That man is not an idiot.” But look: “No one really knows how to code and we’re all stumbling around on a barren heath praying for deliverance.” He’s very poetic, isn’t he?

You must have had days where you’ve just been trying random things to solve a problem. You’ve been trying to do it so long, you’re just trying anything, anything that will work. And then all of a sudden, you fixed it. You just commit it and move on.

How does it all work, really? I mean, I think most people know about the level of technology they work at and maybe a little bit about the levels above and below that, but the human brain can’t encompass the amount of knowledge it needs to be an expert in something like SpriteKit and be an expert in everything else all the way down to the subatomic physics that makes an electron dance around inside a chip.

There is too much knowledge in this field for somebody to know it all. You can’t do it. Don’t expect to try and know everything.

This is a great one. “The most important skill for programmers is being comfortable having no idea what you’re doing.” Almost every time I start something, I’m very comfortable with this feeling.

When Swift first came out, I happened to be at the start of a brand new project at work, and I had one of my great ideas. “I’m going to do this in Swift! What a great opportunity.” So you start the new project dropdown, you choose a language. Swift comes up. How … how do you … how do I Swift? I don’t know!

That’s fine, that’s okay, that’s how you learn things.

Xcode is not very keen on characters it doesn’t like hanging around in places that it doesn’t want them to be, and with Swift in Xcode, your problem down here gives you an error message up there, and it can take a very long time to figure out what’s happening.

Ready to Join the Club?

Hopefully you’ve been able to relate to some of these situations and you’re now feeling ready to join my idiot club. If you’re still not convinced, here’s a recent search of commit messages that you can’t actually read, but it says, “I’m an idiot, I’m an idiot, I’m an idiot, I’m an idiot.” It’s a big club. We’ve got a very open membership policy.

If you’re still not convinced, then maybe you’re in the hazard phase on this graph.

This is a graph, therefore it’s science. If you can read the captions, you’ve got the orange line, which is “How much I think I know”. The blue line is “How much I actually know”, and the green line is “How much more I realize there is to know”.

So let’s assume that I’ve convinced you that you’re idiots. Now we can move on to the third part of the talk: how to idiot.

Step 3: How to Idiot

The first step in successful idioting is to keep in your brain the idea the whole time that you’re an idiot. Don’t give your idiot brain too much to do. Don’t try and remember everything. Write stuff down. Use a task list. Use a code snippet manager. Write notes.

As soon as you get a flash of understanding where you think you’ve figured out how something works, write it down, because tomorrow you will have forgotten. Don’t hold all this stuff in your head; your head can’t do that. That’s not how brains work.

The sign of an idiot who knows how to idiot. (Image: pixabay.com)

And when you’re doing your work, keep on remembering that you’re an idiot. The coworker whose code I spend the most time looking at is probably me, and as we’ve established, I’m an idiot. But I quite like my code and other people like my code. It works, and I get things done on time.

How do I manage that despite being an idiot? I manage it by using my idiocy to make better code. I write for an idiot.

Write for Idiots

I’ve worked on a lot of what we call “rescue projects”, where you get some steaming pile of an app delivered and the client says, “We just can’t get it to work and we’ve got this release next week.”

The standard problem in these projects is always this: it’s too complicated. You can’t look at it and think, “I know what this code is doing.” You have to really, really think about it and tear it to pieces, and it shouldn’t be like that. You should be able to look at a piece of code and understand what it means on a certain scale.

If I don’t understand what a section of code is doing or how it’s doing it or why it’s doing it, then it doesn’t get to stay like that. It might just need comments, it might need a couple things renamed, or it might need complete rewriting, but it doesn’t get to stay the way it is.

I don’t know who the next idiot to look at that code is going to be. It could be me. So I always write for the next idiot who’s going to come along, the next idiot who has to be able to read and understand the code.

I write for this idiot.

Which means you write your code to be read. You spend far more time reading code than you spend writing it. I strongly believe that writing code should be treated like writing prose, mainly because I’ve always fancied myself as a novelist, though I could never get anyone but Ray to pay me to write a book. It means I try to write code that tells a story, that passes my ideas into the mind of the person who is reading it.

There’s a cautionary note here: I’m talking about the kind of prose you might read in a book you pick up at the airport on the way to this conference. James Joyce would not have been a good coder; he’d probably have used Perl.

James Joyce doesn’t know how to idiot. Image via wikipedia.com