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

Transcript

Hello. My name’s Rich, and I’m an idiot.

“Surely not,” you’re thinking. “I haven’t come all this way to listen to an idiot speak.” I’m afraid you have, and today I want to tell you three things: That I am an idiot, that maybe you’re an idiot, and how to idiot.

If I’ve spoken to you before or you saw me this morning, you might not need much persuasion on the first point.

But maybe some of what I’m going to say will resonate with you, and you’ll start to wonder, “Maybe I want to be in this idiot club because of all the cool and successful people that are in it.” If so, you’re going to be interested in point three, because I’m going to tell you how I unleash the idiocy to achieve, if not greatness, then at least non-terribleness.

Step 1: I Am an Idiot.

That’s me on the left.

How can I prove to you that I’m an idiot? I’m standing in a room full of potential colleagues, clients, employers, in front of a massive slide that says I’m an idiot, wearing this T-shirt.

All signs point to idiot.

That’s not the smartest move in the book, is it? I’m giving a talk in public, which makes me incredibly nervous. I didn’t have to do this. I could have come here for free by reviewing the talks, or I could have bought a ticket, or I could have stayed at home in bed. But I came here to do this talk. Why?

I regularly get confused at the most basic and simple things in life. I’ll give you an example: I’ve got two young daughters and they have drawers for their clothes. Two drawers each. It’s the same way I do my clothes. I work at home, so I do all the laundry while Xcode is recovering from crashes or processing symbols or whatever it is it spends most of its time doing. So when I’m doing the laundry and putting clothes away, I think, well, two drawers. One drawer for tops, one drawer for bottoms. That’s how I do my clothes, that’s the only way that makes sense. So I put their clothes away. There’s a T-shirt, that’s a top. Leggings, that’s a bottom.

A dress? Is a dress a top or a bottom? I don’t know. Science doesn’t know. I give myself a different answer every single time, which is probably one of the reasons it takes my kids so long to get changed.

I blunder about with a similar level of confusion at work, which means that sometimes in the cold dark nights, I get the fear. The fear that I don’t belong here. The fear that I’m only doing this job until I get found out.

This dog knows more than I do.

I had no programming or computer science training. I was a biochemist, and then I was a chef, and then I went back to being a biochemist again. I tried to cure cancer. That is really hard. Then I worked a bone marrow registry at a blood bank, and then I thought, “I quite fancy being a programmer.” But I couldn’t get a job anywhere because, of course, I’d had nothing to do with programming my entire life. The only place I could get a job was at a company that had written its own programming language, so nobody who ever applied there knew how to write in it.

So while I was working there and sort of learning the art of programming, which is kind of generally applicable to everything, I taught myself Objective C, I taught myself how to make iOS apps, and I managed to trick my way into a job where someone would pay me to write iOS apps.

But I’ve never had one of those interviews. If you asked me to implement a binary sort on a whiteboard, I’d have two problems:

1. I don’t know what a binary sort is.
2. I’m left-handed, so when I write on the whiteboard, it just gets wiped out.
3. In fact, three problems, because my writing is illegibly bad.

When I’m coding, there are certain kinds of mistakes I make all the time. For example, the greater-than and less-than operators. I always get those confused, even though I know the rule about the hungry crocodile. It just doesn’t fit in my brain when I’m typing it. It’s the same with min and max. If you were in Caroline’s talk this morning, she had a thing where she did the min of this and the max of that and zero and it’s supposed to be one or zero. Every time I try and do that, I always get it wrong.

Today, I work with some super smart people at an agency called MartianCraft. I don’t know if you’ve heard of MartianCraft, but the people that founded MartianCraft literally wrote the books on how to make iOS apps. So you can easily imagine that I sometimes feel like I don’t belong there, that these people probably can use the greater-than and less-than operators correctly the first time they try.

But this is fine. If you think you’re the best person in the room, you’re either wrong, or you’re in the wrong room. If I’m working or chatting at a conference or on Twitter or Slack with people, and I think, “Oh, this person is so much smarter than me, they’re so much better than me,” that’s great! That’s my chance to learn something from them.

Via memegenenerator.net

But, and this is my key point, or one of my key points: it’s entirely possible that those people feel the same way as well. It’s entirely possible that we’re all idiots, and successful people are just good at idioting.

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

You’re Probably Doing It Wrong

There’s another thing I bear in mind when treating my code as prose: I’m probably doing it wrong.

Like prose, there are limitless ways to write anything. If there are limitless ways to write anything, then statistically speaking, the way you’re writing it is wrong. If it’s not wrong, it’s still not perfect, and it might not be the best way of doing it. But that’s not so important. It’s more important that what you’ve written works and that it’s easy to change than that it’s perfect. Because remember: it will never be perfect.

I’ve learned to get comfortable with that idea. It doesn’t matter if what I’m writing isn’t the best or the cleverest or the most elegant or the most beautiful way of writing it. If it’s understandable and someone else can understand it, and if you’re really feeling good about it, it’s got tests, that’s great. It’s much easier to refactor that working code later on than it is to spend a day agonizing over your design pattern, because your customers and your users don’t care. They just want an app that works.

And if you have this idea that you’re probably doing it wrong, that any part of this app could be rewritten at any point in the future, then that app evolves a more sensible and decoupled architecture. You ask yourself, “Is this bit too big? How hard would it be to dump this bit and put something else in instead?” You continue to ask yourself these questions while you’re writing, and you end up with a very sensible structure.

Don’t Be Clever

There’s another question you must ask yourself when you’re writing. “Am I getting too clever?”

I’ve got more quotes about this. Here’s a famous one:

Clever code is unfixable.

Clever code is like eating an entire blooming onion from Outback, which I intend to do on this trip, by the way. You feel quite proud of yourself at the time, but you pay a price later on.

A classic from Outback Steakhouse (Image from outback.com)

Clever code is not good code. Cleverness in code is not a virtue. I spent last summer working on educational materials teaching people how to use Swift, people that had no computer knowledge whatsoever. It was absolutely fascinating to go back to the first principles, to take away all the knowledge I’d accumulated in my own head. What is a variable, what is a constant? How do you tell a computer what to do? And Swift allows you to express those ideas really, really clearly.

Unfortunately, it also allows you to write incomprehensible nonsense. And writing incomprehensible nonsense in Swift is kind of the emperor’s new clothes of our community at the moment.

There are entire blogs filled with stuff like this. Can you tell what this code is doing without moving your lips? Would you be able to tell again in three months’ time? Even the code’s confused about itself—it’s got a face in the middle.

Don’t be that blogger. Don’t write code like that. Don’t let code like that through code review. Don’t encourage people to do code like that. Idiots can’t understand code like that.

Yes, you can do things like this. You can use custom operators, you can wrap things in things that process things and give you a thing all in one line of code. But are you actually helping anyone, or are you just masturbating in public about how clever you are? How many hipster language features you can cram into this one little snippet? Who are you helping with code like this? And don’t tell me that this is easy to “reason about”. It’s not.

Brevity is not clarity. Write for reading. Write for idiots.

That was a small rant. I can now move on to slightly more positive things you can do as an idiot, like: You can ask for help.

Ask for Help

People are afraid to ask for help. They don’t want to look stupid. They don’t want to look like they don’t know what they’re doing. They don’t want to expose themselves as not being an expert.

This is ridiculous; people shouldn’t feel like that.

If you’re afraid to ask questions, how do you think the people that you’re scared to ask good questions of got to know the things that they know? Asking for help is simply how it’s done. It’s not a situation where it’s you, who knows nothing, and someone else, who knows everything. You simply have overlapping areas of knowledge.

In these two diagrams, if you stood in the middle of that blue circle and look around, you’re surrounded by yellow. But the truth is closer to the right diagram than the left. If you make asking questions and answering questions part of your team’s culture, you’ll be happier and more productive.

If you work alone or your colleagues aren’t helpful, you can ask questions on Stack Overflow. Here, you can ask questions about the things you don’t know in front of every developer on the planet.

Let me do a quick show of hands: who uses Stack Overflow? Could you imagine doing this job without Stack Overflow? Keep your hand up if you’ve asked a question on Stack Overflow. Keep your hand up if you’ve answered a question on Stack Overflow. Keep your hand up if you’ve searched Stack Overflow, found an answer, and it was yours from a year ago because apparently you keep forgetting how to do this thing.

Yep, my hand is still raised.

When you’re asking a question on a site like Stack Overflow, you need to use your idiocy. You have to explain things clearly and avoid adding confusing extra details. Imagine that your question is going to be read by idiots, because it will. And a lot of those idiots are going to try and answer your question.

Give Help

How does an idiot answer a question successfully? You use your idiocy.

Ask clarifying questions if you don’t understand. This is a great trick, because sometimes you just say, “Oh, what’s this bit here doing?” And then that person suddenly realizes that that bit there is their entire problem, and they get to feel great, because they’ve actually solved their own problem. You get to feel great because you’ve helped them solve their own problem without needing to know anything.

Remember how it feels when you don’t know something and how hard it can be to ask for help. Don’t act surprised that somebody doesn’t know something that you know. You didn’t know once. Don’t belittle someone for having the self-awareness to know what they don’t know.

This duckling only learned how to swim (and code) by asking helpful idiots on Stack Overflow. (Image via pixabay.com)

Give simple answers, but give clear answers with reasons behind them. Don’t just dump a load of code on people and say, “Try this!”

And of course, you might not know the answer to the question. This is fine. You can move on, or you can do a bit of research and try to find the answer yourself. I learned a lot by doing that on Stack Overflow. I’d see questions and have no idea what the answer was, so I’d go and find out all about the thing. You can learn a lot more that way; it gives you a broader range of things to get involved in than simply making a project, because a project is usually constrained to a few areas.

Go Forth and Idiot

We can see that a strategy for successful idioting boils down to these two points:

1. Communicate clearly
2. Help each other

You have to communicate clearly with yourself and with the other idiots. It’s much more important to be clear than to be clever. You have to realize that your idioting overlaps with the idioting of others, and that we can build amazing things if we help each other and work together.

There’s too much knowledge in the world for one idiot to keep it all in their head, so we literally do have to share it; there’s no other way.

Thank you very much, idiots!

The post RWDevCon 2017 Inspiration Talk: I’m an Idiot by Richard Turton appeared first on Ray Wenderlich.