Foreword: I added some information since the initial Medium publication at Starting Day One as the publication is no longer being maintained and wanted to preserve the data for historical archives. I have since edited minor grammar mistakes, added additional information about Chris’ portfolio of stuff he built in 2022, paraphrased the questions to provide clarity for the audience, and labeled any other person’s questions as the “audience.”
On July 20, 2015, I hosted an AMA with Chris Oliver to get some of the burning questions answered about work, life, and everything in between.
Thanks to Erik Finman for letting me use his platform to host this online interview with Chris Oliver.
About Chris Oliver
Chris Oliver was a lead developer at One Month, the current founder of GoRails, Hatchbox, and Jumpstart Rails, and co-founder of LaunchCode. Oliver has been a phenomenal influencer in the Ruby and Python community. He has been writing Ruby code since his early days before migrating from Python. Kudos to friends at One Month for promoting this story. He now has a podcast called Remote Ruby with his partner Jason Charmes and Andrew Mason, and you should check his latest podcast here.
Oliver to everyone at the Day One Programming Facebook Group: What challenges do you guys face when becoming a programmer?
Me: When I first started programming, I didn’t know anything to start with. So, I self taught HTML/CSS to get started. I fell in love with it ever since. Then, I now practice Ruby and Rails thanks to one of my mentors who wanted to get me involved with the Ruby community.
Oliver replied to my comment:
I first learned GW-Basic in 7th grade and tried to make games. Started with building calculators and decided to make a hangman game. I spent so many hours of my life building that and it could only ever support 3 letter words. It was terrible, but I rewrote it like 5 times. The first time was 38KB. The last time I built it was 2KB and it supported colors, words or phrases of any length, and all kinds of things in 1/14th of the size. Just finding something that you enjoy hacking on no matter how useless it is makes all the difference.
Rod Argumedo to Oliver: What was it like working at One Month?
Life at One Month has been interesting. We’ve come a very long ways from where we were a year ago when I started. I was the 6th employee and first full-time developer. Now we have 11 employees and a handful of contractors helping us. Challenges have scaled as we have, so you can look back and laugh at the things we worried about a year ago compared to what we worry about now. I spend the majority of my time helping support everything people are trying to accomplish. I help refine ideas, decide what’s important, and actually implement most of what you interact with on our site. The software problems range from collecting email addresses, automated billing, failed credit cards, welcome emails, video playback speed buttons, marketing sites, integrating Discourse via JSON, you name it.
Erik Finman to Oliver: What made you join One Month?
So I joined One Month about a year ago to join a company doing the same things I was alone. I have a site called GoRails that I’ve been using to teach Ruby on Rails for a while. That has been fun but also very hard to do alone. I joined One Month to work with the team on shared goals of helping people actually become great programmers.
Audience question for Oliver: I am learning Python, and after learning the basics, I now don’t know what to do next. How to practice more to be a successful programmer like you?
That’s a great question. I actually started learning programming with GW-BASIC and eventually found Python. It’s an amazing language and I learned a bit about how to build desktop software with it but wanted something more. I started scouring job boards for someone who wouldn’t mind hiring a newbie in Python. I found a guy who hired me really cheaply to teach myself Django and build websites for him. I had so much to learn, that I probably made $0.50/hr at the end of it, but it was worth it. That was the very first time I made money as a programmer and it got me so much further along. I’d try to see who will pay you and you’ll be surprised that people often pay you to learn new things for them. A couple years later I got hired to learn Rails and that’s how I started doing that full-time.
Rod Argumedo to Oliver: What is your best advice for programmers new to any programming languages? Any tips?
If you’re trying to learn a new programming language, figure out how you can compare it to what you already know. I’m learning React right now and the easiest way to go about it is by taking my knowledge of jQuery and AJAX and trying to convert code I’m already familiar with to React. When I went from Python to Ruby, I just tried to figure out how to convert what I would do in Python to Ruby and afterwards I tried to learn what made it feel like good Ruby code. Once you’re capable of doing some things, it’s much easier to learn the nuances of the language and how it can help you in specific ways. You’ll save yourself a lot of time just by taking it one step at a time.
Rod Argumedo to Oliver: Have you ever been to a hackathon (a.k.a coding competitions) before?
Yes, I’ve been to a bunch of hackathons. I’ve actually met some of my closest friends at Startup Weekends. They are a great place to just have this intense atmosphere for a weekend and knock out something you’ve been meaning to do for ages. This has been such an important part of my life, that I spend almost every weekend hacking out super late at 24 hour coffee shops coding with headphones on and trying to learn something new. There’s a wonderful feeling you get when you do that. You’re working hard making the world go round when everyone else is out drinking. :)
Audience question for Oliver: Do you think it’s better to specialize or generalize when it comes to learning design or development? (i.e., Learn a little about most things or everything about one?)
Audience question for Oliver: Do you find it easier to work with dedicated front-end developers, or do you prefer to manage both ends solo? How do you manage your workflow so that your front-end developers can keep pace as you add/remove features?
Killer question. That’s definitely a tough one and depends a lot upon the team you’ve got. I think with someone like yourself who has a solid background in frontend, it’s much easier to have a frontend developer. We can basically just design the interactions back and forth (the JSON structure, APIs, etc) and both of us can work independently to accomplish so much more. That said, if someone’s new to frontend, it can be sort of a burden and it can often be easier to handle it myself at times. With the new frontend frameworks though, it’s starting to get so complex you almost need a dedicated frontend and a separate dedicated backend person to really make kickass products.
Audience question for Oliver: What are the most needed skills/gems/techniques you use in your daily programming as a Rails developer?
All you need is RVM if you are using Linux or RubyInstaller for Windows and download version 2.1 as 2.2 does not work with Rails at the moment with one of the gems is not supported for Windows at this time.
Audience question for Oliver: With so many great front end frameworks that exist, which ones have you found best fit in with the RoR workflow/framework? Have you found any that just don’t fit in no matter how much you want them to? Do you prefer that Rails handles the entire stack and not introduce additional infrastructure?
My conclusion lately has been with React. Google didn’t intend Angular to become what it is now. Throwing it all away and rebuilding from scratch was great, but they’re pretty notorious about not supporting their developer tools so I’m hesitant on it. Ember is great, but I’ve noticed they are just becoming this snowball rolling up every feature anyone else has come up with. I’m kinda disappointed with it because there’s less new great ideas coming from them. React was really refreshing to see for me and it’s the one I feel strongest about. Facebook created it out of the issues they were dealing with and that’s lead to some really interesting insights. I love that out of the box you can have it render things server side. It’s obviously needed for SEO and such a simple solution. React itself is also really simple as a concept. It’s more or less what jQuery should have evolved into. The disappointing part about this area though is Flux. There’s no standard implementation. Everyone has opinions, and nobody agrees how to do it. That’s going to be the main point of struggle with React. All in all I’d say #1 React, #2 Ember, and #3 Angular.
Audience question for Oliver: What steps (in what order) do you take when you plan + implement a new feature in case you have never done it before?
Great question. I’ll actually point you to my vlog because that’s exactly what I’ve been doing lately. I wrote a calendar gem for Rails and I knew I didn’t like how messy the code was. It didn’t seem right but I didn’t know the right answer. I just experimented with some ideas and it turned out to be simpler code than I ever imagined it would be. In fact, we implemented a calendar from scratch in under 15 minutes. That’s something that took me hours the first time I did it but just sitting down and breaking the problem down into tiny pieces produced a flexible, functional calendar in Rails in no time.
Audience question for Oliver: What practices/habits have helped you understand new (abstract) programming concepts?
As far as habits go, really just figuring out how to get myself in the zone as quickly as possible. I need a bit of caffeine, headphones, and a quiet space and I can start thinking very clearly. Making that a habit is step number one so you can easily jump in when you want rather than having to fight yourself to start. After that, I spent a LOT of time rebuilding other applications. I made my own IRC client and IRC bots in order to learn how to build event driving applications and talk to raw sockets over Ruby. If you try to rebuild your own browser, web server, twitter, facebook, instagram, email client, you’ll get so much insight on how all these apps work. The reality is they are all pretty simple.
Audience question for Oliver: I noticed that you didn’t really touch on TurboLinks. Interested on your thoughts with the way it interacts in Rails. I’ve had terrible luck using it on a large scale application, curious of any use-case you’d had success.
Audience question for Oliver: Can you recommend any good practical tutorials to rebuild things?
The goal is not to have to follow a tutorial. You’ll probably need to do some to start like Rails Tutorial to learn how to build Twitter, but the real goal here is to figure out how to build these things without any tutorials or advice. The reason is that you’ll get to discover all the problems they did when they built these the first time. You’ll get to learn how the developers of those apps think because you’re solving exactly the same problems they did and they didn’t have any help when they started. That’s an invaluable experience to have and it sort of requires you to have nobody holding your hand. It’s definitely hard, time consuming, but it’s very fulfilling and you’ll make so much progress in your skills and confidence. That said, you will need some tutorials to get you familiar with just enough to start. I often google things like “How to open a socket in Ruby” and then I’ll copy some code from a generic tutorial and repurpose it for what I’m trying to do. Don’t be afraid to use tutorials as helpers along the way, but just don’t follow them word-for-word.
Audience question for Oliver: Do you think it's necessary to learn computer science topics (algorithms, etc.) while learning to program, or would you save that up for later?
Super good question! If you asked me this a couple years ago, I would have said no. Now, I’d probably say yes. I went to school for computer science and didn’t learn hardly anything. Those algorithms and data structure questions meant nothing to me then and weren’t applicable at all. As the years went by (like 6 years later) I actually use all those things pretty often. They guide my thinking and make sure that I don’t write some poorly performing code. I can use the data structures to my advantage but at the end of the day, they aren’t super crucial. I built a lot of things and hadn’t ever learned anything formal. There’s a time when you feel frustrated that your code is slow, or it sucks, or you just don’t feel comfortable in your skills. That’s usually a sign that you should spend some more time learning the theory. I think at first focusing on just building things is important. Once you can build things, then computer science knowledge helps you build better things. It probably makes sense to sprinkle it in a lot along the way, but learning that stuff alone (like they teach in college) won’t help you finish any projects. A balance of practical skills and computer science theory is ideal.
Audience question for Oliver: How do you keep/retain your programming knowledge? With so much stuff to learn, it would be a pity to have it fade away when not used regularly.
It can definitely go away slowly, but it’s kinda like riding a bicycle. You can still pick it up later, you might just be a little off balance and rusty at it. Programming is really just about learning a new way of thinking and breaking apart problems. It’s not something that will necessarily go away if you don’t keep doing it. But that said, so much is changing that it can’t hurt to always be practicing. That’s one reason why I started doing a daily vlog. Sometimes I end up doing lots of project management or planning at work and don’t get to code for a few weeks at a time. I decided to do a daily open source vlog (which hasn’t actually been every day) but it has really helped me get back into coding every day at least for 15 minutes. It’s definitely worth trying to do.
Rod Argumedo to Oliver: Whenever you make a Rails application with scaffolded models with ActiveRecord, do you mainly follow the SQL normalization practices? I feel a lot of people get confused all the time about what normalization is.
I never had a formal understand of SQL. I taught it to myself so that I could do Django. It was so confusing. It took me years to understand what “normalization” meant. These days, I’m very critical of people who throw around words or design patterns like that often. It’s usually a sign people are just following some “rules” that people talk about often without knowing why. Normalization is this thing that simply doesn’t matter unless it does. If you’re trying to store a user with many projects in a database, you HAVE to normalize into separate tables. Otherwise, don’t do it. You’ll notice that you’ll discover the reason for normalization. Sometimes you want to optimize for saving storage space. Other times you want performance and it’s important to denormalize. The real key here is that it’s only useful when you need it. If you try to do it without knowing what it’s useful for, you’ll never appreciate it for why it really exists. I like to learn things the hard way and then discover “ohhhh this is normalization and this is why it’s important!” and then you’ll have the best understanding of it you could have.
Audience question for Oliver: When starting a project, do you begin with the UI or database schema first? What to do when you are unsure about the schema structure?
I often go back and forth on UI or schema first. Usually I can start with the schema the easiest. You know what data you’ll that’s required and that makes it easy to start building the relationships. That said, starting with the UI can give you insight into those extra schema details you might not have realized until later. If you’re not sure of the schema, starting with the UI will help you determine what fields you need to display. Ideally, you can keep both of those in mind and that’s when you’ll be the most effective. I spent time doing both directions a lot and can now do both at the same time (sort of) and that makes things so much more flexible.
Rod Argumedo to Oliver: To close this AMA, what are your finals words to all current and future developers?
My advice to current and future developers is going to be the opposite of what most people tell you. Just focus on just building things. Don’t worry about testing, design patterns, performance, or anything else. Those are tools to help you build things. Just focus on finishing and releasing your apps. When it gets messy and hard, that’s when you can learn about design patterns or performance or testing. The right time to learn those things is when you need to. Feel free to explore. Just dive in, don’t be afraid of not learning things the right way.
Thanks guys for all the questions! I’m happy to continue answering questions if you’d like to email me or something. I’ll probably be a little slower to reply, but I’ll make sure they get answered.
Major thanks to Chris Oliver for having a great interview with me and the audience for the Day One community group.