Peter Fisher; freelance web developer and host of the popular “How To Code Well” podcast; discusses why he started teaching coding and some of the best career advice he has given.
I never actually wanted to be a programmer. I actually started off from an arts background. So I did a lot of graphics design and a lot of 3D animation. We did a lot of flash animation and action script coding, so the coding came alongside the multimedia stuff.
When I was at school, I was building small little websites for myself and friends just to post images on. And I found it interesting that one could build something with really small feedback loops. All you had to do was write some HTML code and refresh the page and you had something.
And then when I got my first job in a web development agency, I discovered very quickly that I wasn’t actually a graphics designer as more of a coder. So, I was able to transfer my passion for design to a passion for designing and architecture.
I never started How To Cope Well with the intention of building a business from it or being a creator. It was a purely accidental thing that I got into. I always started blogging when I started learning because that was my way of keeping note. But I was writing to myself rather than to others.
After I finished university, I was in this ocean of developers who’ve just come out of university, and they were all looking for the same jobs. I was speaking to a lot of recruitment agents, and one of them, off the cuff, said “I wish there was a way I could show our clients how well you can code.” This was like 2006-2007, so YouTube was just coming out. And I thought: “You know, that’s something people is starting to use more, so I will video myself doing some code.” It was a very selfish decision. It was never intended to teach anyone how to code, it was just to show how I coded, so I could have called it How Well I Code rather than How To Code Well.
At first, I did about four videos and posted the links up onto my CV, but I very much doubted that anybody would actually see those videos from a job perspective. So, I forgot about it for a few years and didn’t bother logging back into YouTube.
Then one of my family members wanted to post or share a video for other family members. And I just thought “Oh yeah, I’ve got this YouTube account.” So, I logged in and, after several years of it being dormant, I noticed that there was a ton of comments and questions and feedback which were all very positive. I thought this was something I could run with, and it went from the very selfish decision of promoting myself to helping people out. People on YouTube were asking if I knew how to do other things, how to use other programming languages, where the next part of the course was. The funny thing is that I never thought it was a course when I did it. The driving force of How To Code Well is its community.
I was a junior dev working a full-time job with freelance work on the side, and I was now teaching people to code, so time was and is a thing that is against me.
I’ve got a very strict rule of not doing it during working hours, so it’s evenings and weekends, and over several years I’ve managed to keep that going. But there’s a lot of sacrifices one has to make. For instance, if I live code on YouTube on Tuesdays after work, my working day is prolonged, and my downtime is shorter. If I live code on Twitch on Sundays, my Sunday afternoons are out of the water. And there’s a lot of preparation that you have to do before you do that. You need to think about what it is that you’re going to code and talk about.
Impostor syndrome is something that is definitely real, and with the podcast that came through accident as well. I started doing long-form content where I was touching upon subjects that I didn’t know much about. It got to a point where I was getting to the limits of my knowledge, and I just decided to bring people on the show to learn from them. It’s always a learning journey, always knowing where my limitations are.
With every course I build, I think that I’ve done the wrong thing, if I’ve said the wrong technical thing. You know, if I’ve pronounced an acronym wrong. You’re constantly doubting yourself. It does get easier because you get used to that feeling and you can have a little word with yourself and say “It’s fine. It’s okay, you can publish it.”
You’ll never truly know how the audience is going to react until you publish it. So, every doubt that you’ve got in your mind is just your doubts. It’s not the doubts of others. I think that’s how I get through it.
Speaking to people on the podcast who know about the subject matter, I do come away feeling like I know nothing. I know what they’ve said because I’ve understood what they said, but it just makes me aware of how little I know of web development, which is another reason why web development is so good, because there is so much to know and so much to learn, it’s endless. You’ll never learn everything.
From a technical standpoint, a good web developer knows the syntax and the processes. But a great developer understands the technical consequences of those processes and decisions, and they can lean upon past experiences.
Also, a great developer is highly professional. They know when to say no and they have justifications of why they’re going to say no. They have testing, they know how long things are going to take, they have some experience behind what they’re doing. They’ve seen it from inception to deployment, and they’ve gone through the whole bug fixing cycle. But really, I think what boils it down is experience. You can’t just learn to be a great developer, you must embrace it and experience it.
What I see a lot is people diving into frameworks and then getting stuck when they move to another position or another job, or when that framework changes. They are comfortable in that world, but they’re not comfortable in the world outside of that framework.
Take breaks. Take more breaks than you think you need to. Your brain works offline, so even if you’re not physically at your machine, you’re thinking about the work. I think about the work when I wake up and when I go to bed. I never switch off in terms of thinking about the bugs that I need to fix or the logical flows, but because I’m not staring at a screen, I’m not getting stressed about it. I’m processing this information in my brain in the background. And, when you come back to the code, it’s easier to identify the issue that you are in.
The second one is to keep asking questions. Web development is super hard and it’s going to get harder. You think you know it now, but, in two years’ time, you’ll know two years’ worth of it, and then you’ll discover another two years that you don’t know. There’s more stuff in web development that I don’t know than there is that I do know, and I’ve been in it for a long, long time. Don’t beat yourself up and if you don’t understand what you’re trying to achieve, then ask someone. And, if you don’t understand what that person is saying, ask someone else, because perhaps that person hasn’t talked about the answer in a way that you can absorb. Maybe you are more of a visual learner. Maybe they can show you on a whiteboard or take you through the process. Throwing acronyms at someone isn’t a very useful thing, is it?
Lastly, technology comes and goes. At university, I studied visual basic and action script. Well, action script is for Flash. Flash is never used. And visual basic, I just wouldn’t even know. I did well in that course, but I’ve never used it. What I’m trying to say is that technology comes and goes, and whatever you learn now probably won’t be the thing that you will be learning in 10 years’ time or doing in 10 years’ time. So, what you need to do is accept that and embrace change, but don’t embrace change every five minutes.
And the only thing would add is to just enjoy it. Don’t get too stressed with it all. It’s a very challenging thing, and I find that, the more I get stressed, the more I dislike it. So, once you find that you’re actually getting stressed and frustrated with something, take a breather, take a couple of hours. The code will still be there tomorrow, so take an evening off.
How To Code Well is a video podcast which is live on YouTube every Thursday at 20:00 BST. The audio version is released every Friday and is a week behind the live show. You can find it on iTunes, Spotify and most other podcast platforms.
Connecting Europe’s top IT talent with the most innovative brands