Introducing Raphael Serota, Lead Instructor for Web Development Bootcamps

Raphael Serota is one of CodeCraft’s newest employees, and we’re excited to have him join our team as the lead instructor for our Full-Time Full-Stack Web Development Bootcamp. Here’s a little bit of Q&A we recently had with Raphael about his background, his approach as an instructor, and how bootcamp students can make the most of their time both as students and later as graduates.

Q: Tell us about your background: you went to college but didn’t study computer science?

A: That’s right. My experience with getting into web development was atypical. I earned a Bachelor’s Degree in Cognitive Science from Hampshire College, in Massachusetts. I mainly focused on the psychology of decision making, especially how people interpret risk and uncertainty. I also studied quite a bit of the psychology of education, so that’s been more directly relevant now that I am an educator. But I didn’t study computer science.

Q: How did you go from studying psychology to being a programmer?

A: The college I went to required that I spend my entire senior year creating a research study. So while doing that, I decided I needed to teach myself to program in order to create the experiment I wanted, which would gather data and analyze it. I didn’t know anything about programming at the time, but a friend told me that learning Python (which is a programming language) was as close as you could come to speaking English with your computer. So I went to Barnes & Noble, and picked up the skinniest book I could find on Python, and read it cover to cover. That’s how I got started. (On a side note, that’s the last programming book I ever read! I’m still constantly reading about programming, but these days, it’s mostly forums, blogs, tutorials, guides, etc.).

“I went to Barnes & Noble, and picked up the skinniest book I could find on Python, and read it cover to cover.”

After I had finished college, I wanted to go to graduate school, so while applying to grad programs, I got a job at a neuroscience laboratory at Wayne State University in Detroit, Michigan. I worked at the lab doing data analysis and experiment presentation programming. My job was to write the software that would show patients images, and we’d take “functional” MRI scans (fMRI) which are like taking a video of the brain as it processes the images the patients saw. Working at the lab, I realized that going to graduate school would be a long and complicated process that would take many years, but the programming I was doing was not long term. I could write a program, and the very next day, the other people in the lab would be using it to automate the tedious tasks in their daily life. They would tell me how useful the programs I wrote were, and they were so thankful. I decided that programming was the most fun I had in that lab. I liked it better than all the other aspects of academia.

Q: By now, you know a lot about programming and have worked as a developer in the past. Why did you decide to become a teacher?

A: It’s way more fun! I have worked as a developer for a few companies in Boulder, doing “the 9-5 developer thing.” But the day to day experience of teaching is fun for me. I like explaining things; I am kind of a pedantic person—I feel like I have a good understanding of how the Internet works and how coding works, and I frequently see that these concepts are explained poorly. I like to think that I can do a better job explaining them, and I like to help people get into the industry. With the actual code that I write during the day, the examples I make are fun, and I like to make silly applications to illustrate a concept. As an instructor, I can do this, because I don’t have to be generating business value for an employer with the actual applications I build, so that helps me be a little more creative and have a bit more fun as well.

Q: What is your approach to teaching web development?

A: My approach to teaching is this: I cannot shove knowledge into your head. You’re not going to learn passively by just listening to my lectures. I do have quite a few lectures in the course, but my expectation is that students listening to lectures are not going to immediately understand these concepts just because I explain them.

When I explain a concept over the course of ninety minutes, it’s a very concise, fluid explanation. Sometimes students feel like “Raphael made this sound so simple in class… why can’t I remember or understand it?” The truth is: when I was learning programming, I would read a blog post that explained a concept concisely, but I wouldn’t get it. Then I’d read four more blog posts that explained it in different ways, but I still wouldn’t get it. Then I’d actually write some code, and try to do the thing all these blog posts were talking about, and only after I did it with my own hands a few times would it finally make sense.

My overarching philosophy is: with a lecture; I can’t teach you everything you need to know to be a developer. But I can teach you enough that you can make mistakes on your own, and through making mistakes—figuratively banging your head against a wall—that’s where you actually learn how to code.

“I’m basically explaining how to swing a golf club and I expect to watch you fail repeatedly until you can learn to get the ball close the hole.”

I often like to compare learning programming with learning physical skills in that you have to develop muscle memory. For example, imagine you’re learning how to swing a golf club. That’s a very precise physical skill, and there are a lot of academic concepts that go into it: you can study the rotation, the inertia, the muscle groups you’re using, etc., all day long. A really sophisticated golf instructor could talk for hours about “the proper form of a golf swing,” and if you listen to that, you might feel like you understand it. But that’s very far from being able to swing a golf club properly yourself. So I’m basically explaining how to swing a golf club and then I expect to watch you fail repeatedly until you can learn to get the ball close the hole.

Q: In your opinion, what kind of background or personality type makes the best kind of student?

A: I feel like I have different ideas on this than other people in the industry. A lot of people say you’ve got to be “very logical.” But I studied logic in high school, and I use what I learned in maybe the first week of that course as a programmer. You don’t have to be a master logician… there is some “if this then that,” and maybe some “and’s and or’s” mixed in, but it’s not outrageously complicated logic.

Also, people say you need to be really good at math—I disagree with that too. I’m pretty good at math, but the truth is that in programming, the computer does the math for you. You just need to know how to talk to the computer and tell the computer what to do. I think of programming as more of a language skill.

So I have two specific thoughts on the kinds of people that might make the best students:

First, I look for people with creative backgrounds. English majors, I think, tend to make better programmers. Particularly fiction writers. I remember when I was in high school, I had a bunch of friends who wrote fan fiction—you know, Harry Potter fan fiction—they’re taking this huge universe with dozens or even hundreds of characters and trying to incorporate their existing relationships with each other and then also designing new relationships between all these characters that change over time. And I imagine these people are drawing up these really complex storyboards and it’s all using made up names. That’s a big complexity, similar to your challenge as a web developer. With web development, a lot of the hard stuff you have to do is just keeping track of all this stuff that has different names that you had to come up with. You have to name everything you make, and you keep track of what its role is in this broader application—your broader story—and keep track of how that changes over time.

And there’s also the immediate physical aspect of being willing to sit in front of a computer for hours on end. Which fiction writers are comfortable with. I’ve met a lot of people who are judged by non-coders to be good potential coders because they’re hardworking, determined, good math and logic, etc. But many of these people… they just hate sitting down in front of a computer. So even if you’ve got all those other abstract qualities, but you don’t like the concrete activity of programming, you’re not going to have fun.

Second, more generally than just writers, people who are “makers” do well as programmers. You need to have a love of making something and polishing it until it’s presentable to show to the public. Programming is not a performance skill. You can mess up ten times in a row while nobody’s watching as long as you finally figure it out at the end before you publish it. That’s something that appeals to makers—where you can work on something alone, and you can mess up a whole bunch but you finally get one version of it that looks good. That’s the one you actually show to people and hang up in your gallery. So makers are people I look for.

Q: How much can a bootcamp student actually learn in just twelve weeks? Is that really enough time to produce competent web developers?

A: I think our students are actually very prepared. In some regards, I feel like they’re a lot more prepared than students from other programs. I have interviewed several graduates from other programs and one big difference I’ve noticed between what we teach at CodeCraft and how some other programs work is that many other bootcamps are very focused on one specific stack. They might teach just the MEAN stack (MongoDB, Express, Angular, Node), or the MERN stack (MongoDB, Express, React, Node). But what I’ve found is that students who learn just that stack are really out of their element if they’re asked to work in some other environments.

For CodeCraft’s web development bootcamp, we do use one stack (MEVN: MongoDB, Express, Vue, Node) but what I’m about is teaching evergreen skills—things that are never going to change. So I have a really big emphasis on teaching Linux, the command line, and Git. Those are enormously popular tools developers use every day and they’ve existed in pretty much the same form for decades and I don’t see any reason why they’re going to change in the near future.

“Every web framework is going to have slightly different concepts… but underneath it all, it’s all the same internet.”

Also, I’m big on “web fundamentals” — answering questions like “How does the internet work?” I do this because every web framework is going to have slightly different concepts for how you work with it, but underneath it all, it’s all the same internet. If you understand what’s happening behind it all, it’s really easy to transfer from one framework to another.

Q: How can people enrolling in CodeCraft’s Full Stack Web Development bootcamp (or any bootcamp in general) do well and excel as a student and afterward?

A: The students who excel in bootcamps are the ones that have an aspect of curiosity. People who do exactly what an instructor tells them to do and nothing more, where they come to the lectures, they do the assignments and get passing grades… they will be employable. But they may not love the job they end up with, or they might not be making as much money as they could. The students I really love to see are super curious. I’ll be explaining some concept in the lecture and they just can’t help but ask questions, and they want to go deeper into the topics we discuss in the classroom. They also go to Meetups. Just exploring the community and meeting other people is a really important of being a curious coder.

Also, I always encourage people to apply for jobs that they’re not qualified for if only to talk to the interviewers about what they think is important for an applicant to have. Interviewing for jobs in the past is how I really got to understand deep, complex topics like REST, and how I got to really care about them.

“I always encourage people to apply for jobs that they’re not qualified for if only to talk to the interviewers about what they think is important for an applicant to have.”

It’s important for you to never be the smartest person in the room. I know a lot of people hate feeling dumb, and they hate asking “stupid questions.” I think you need to be comfortable with feeling stupid as a developer. I think that on the road to being smart you will sound stupid many times. I encourage you to try to hang out with people that know more than you, both as a student, and later, as an employee. When you do get a job, you should hope you’re not the smartest developer on your team. I often recommend that students join a medium sized company for their first job so they can get some mentorship. It’s nice to talk to the senior developers and ask them to review your code or just ask questions as they come up. Even shooting the breeze with them at happy hour; you can learn a lot about programming culture and learn some code jokes.

Finally, go to meetups, and be a part of the community. Find out how other people talk about technology. You can read about a topic in a textbook, which is very dry and abstract… but you can meet people in the real world who work with this stuff on a daily basis and have to make choices about picking one technology over another technology. These people have strong opinions about certain things, and I think finding out why they have the opinions they do is something that can really take you above and beyond what you’ll learn in a bootcamp.