Question: I watch numerous programming screencasts and videos, and feel that I understand them, but when I actually start coding, I draw a blank and struggle to write even a few lines of code. What am I doing wrong?
You’re not alone. It’s a problem that seems to plague new developers more than it has in the past. The programming ecosystem is actually much larger and more complicated today than it was when I started programming in 2000. I would say a good majority of the students I teach struggle with this very issue. What I’ve seen is that it boils down to three main points of failure or some combination thereof:
- The app idea is too big
- Comprehension is too abstract
- Your stack is too complicated
I seriously have not yet seen an outlier from these three issues. Usually it’s a combination of two, but one is often a greater issue than another, so focus first on the greater issue and ignore the others.
The app idea is too big
There is a reason why startup culture focuses on building an Minimum Viable Product (MVP). It’s not just about getting a product to market as quickly as possible. It’s also about support, initial time investment, and maintenance. The more features that your application has to support, the more overwhelming it will be. I get it, you want to be a master architect and abstract your models/controllers/classes and do things all the “right” ways from the get-go. The problem with your assumption here is that it’s not necessarily the right way.
Start with little things first. Don’t think about the app as a whole or how a single block of code fits into the big picture. I put it this way to most developers:
You cannot build a car if you don’t understand how an engine works
You can follow all the right steps for assembly, and you may be able to assemble the car, but you will not be able to tune, fix, or debug issues with the car if you don’t understand the components that make the care. You are basically hoping for absolutely perfect parts with a perfect manual to assure that when you assemble the pieces it will run.
So how do you put this into practice? Build the smaller pieces first outside of the main project. Let’s say you’re building a mobile app that will talk to the github API and fetch repos. Start by creating a new project that does just that all from the main point of entry. Don’t worry about abstraction, or having bloated controllers, or passing state or storing data. Just write the function that fetches the repos and returns results. Do this with all the pieces and then afterwards you can start assembling them into the whole. This process is something even seasoned developers do. We call it
refactoring. We know and accept that our first pass at the code might be total shit, but we get it working and then we start over or clean up that mess until we have a pretty and perfect component.
Comprehension is too abstract
I have seen this a great number of times with Rails developers that have gone through bootcamps. They have learned all the rails conventions, their code is nice and clean and organized. They can scaffold as fast as some of the most senior developers. However, if you asked one of them to write a single Ruby script to import a CSV list, parse it, scrub it, and save out a new list, they would probably struggle with this task. Even more so if you told them that they couldn’t use any gems. In fact, this very scenario is one of the dreaded white-board challenges that you may face if you apply to a tech giant. If you really want to understand the problem, go look at the source code for rails. Until you are ready to leverage the syntactic sugar and magic of such a massive framework, you need to understand the fundamentals of the ruby language. If you understand the problem, here are exercises that will help you prepare for working with Rails or other web frameworks.
Build a web server from scratch
I challenge you to not use packages or any third party code whatsoever. You can solve this challenge hundreds of different ways. You may build your routing by using regex matching or parsing request headers. Your data storage could be nosql, sql or even flat files stored in the project folder. You will learn and understand so many fundamentals of a language if you complete this exercise, and you will also start to realize how much magic frameworks is doing for you. This exercise works for many other web languages and frameworks much the same. Here are the features you should aim to support, build and understand:
- Build a web server with your language as bare bones and naked as possible
- Make routes for that server:
- Foo and Bar should output a simple string
- Foo and Bar should call different functions to handle the request
- Now connect to a database
- Make your routes RESTful. Make full CRUD operations for
Parse a dirty CSV and save a clean version of it
Both the web server example and this one are often used in interviews to understand a programmer’s comprehension of a language. Having been a CTO of multiple companies and over a hundred developers over the years, I’ll tell you plain and simply:
I don’t care how much of a wizard you are at Rails/Node/Whatever.. if you cannot build a web server, create your own operators, extend std lib classes or write regex matchers.. then you’re not qualified for the job.
Here’s a good challenge to test your comprehension of a language. Take the following source and scrub it:
first_name, last_name, phone, city, state Clay McIlrath,,517-755-8297, Lake, MI John, Doe, (123) 555-1212, , CO Jane, Doe, +1 502.124.1245, orlando, Florida
It should look nice and pretty and standardized and output like this:
first_name, last_name, phone, city, state Clay, McIlrath, +1 (517) 755-8297, Lake, MI John, Doe, +1 (123) 555-1212, , CO Jane, Doe, +1 (502) 124-1245, Orlando, Florida
Working through this challenge requires you to know basic string manipulation, how to set/get array values, and some simple regex matching. If you can’t complete this, seek out the solutions or get help from a more senior programmer who can help you through the pain points and help you understand the solution better.
Your stack is too complicated
You have already seen me dog on Node.js a couple times in this article, and it’s not because I think the framework is garbage. I just know way too many developers that got started with Node.js that hit a limit in their understanding of programming and struggled to progress or work with other languages. If you are working with frameworks that you don’t understand, than you will struggle to debug issues in your application or identify where the point of failure is. If you’ve been programming for even a short amount of time, you have probably encountered a stack trace. Have you ever stared at a stack trace and wondered what the hell all that jumbled output meant? Did some wizard developer seem to understand your problem and help you debug it just by looking at your stack trace output? This is because they understand your stack and you don’t. Even low level languages go through multiple parsers/compilers/languages as they resolve down to a machine language command. I’m not saying that you need to understand Assembler overnight, but you should at least know your core language well and probably part of the underlying language.
If you are working with a framework you don’t know well, spend more time in the source of that language or framework. I like to spend about 30 minutes everyday reading source code, before I start working on anything of my own. Right now, I’m working with React and Redux and little by little, I have come to know the underlying methods and classes of both of these frameworks intimately. My first React project worked great, but as I have learned more about the frameworks themselves, I have gone back and refactored old code to leverage some of the better practices I have learned over time. This makes for code that is easier to maintain, more performant and I can track and see the results as my comprehension has evolved.
I’m available for hire, tutoring, or teaching. If you’d like to work with me in any capacity, don’t hesitate to reach out. I run a small consultancy called Unicorn and we have worked on projects of all size and budgets, so no project is too large or small for us to help lend a hand!