My FeedDiscussionsHeadless CMS
New
Sign in
Log inSign up
Learn more about Hashnode Headless CMSHashnode Headless CMS
Collaborate seamlessly with Hashnode Headless CMS for Enterprise.
Upgrade ✨Learn more
The Diving Right Into Code Problem

The Diving Right Into Code Problem

Todd's photo
Todd
·May 5, 2017

I've both witnessed this problem myself as well as heard countless other, mostly senior developers and managers, bring it up: When a Jr. Dev is too eager to start coding before he/she fully understands the problem.

This affliction seems to be a relatively well-known one, but it definitely still persists. I wanted to dive deeper and think about why this happens, and I came to a realization that much of it likely has to do with how we are teaching new programmers.

The problem is, when programming is taught, too often we teach "coding to code." This includes Hello World programs, "exercises" and other fundamentally-useless programming assignments that are just there to "help the student learn the language syntax."

The reason why this style of education fosters developers who dive into code without fully understanding the problem is because they began writing software at the fundamental stage without any real problem to solve. When months down the road they do face a real problem, they approach it the same way they have been approaching these "contrived" or educational problems, which does not translate well at all. In my opinion, this is a huge mistake in programming education. I also am shocked that some instructors feel that they cannot teach the language whilst also teaching how to problem-solve properly with it simultaneously, or that students can't yet "handle a real-world problem." I found quite the opposite to be true. Gordon Zhu over at watchandcode.com does a fantastic job at doing just this. In his program, he first presents the problem that needs to be solved, he then goes through how to think through the problem and plans out solutions before touching code.

Another example is Sahil Dua's blog post. In it, he explains how he literally learned to code by contributing to open-source. Now, at first glance, this may seem like he just "jumped into code." However actually, one of the biggest reasons newbies often don't get into decent-sized open-source projects is because they have to learn about and understand the problem first. After all, in a deployed open source project, you're solving real-world problems, not tick-tack-toe.

In book form, I thought Think Like a Programmer: An Introduction to Creative Problem Solving by V. Anton Spraul did a fairly decent job of this as well. In this book, the author focuses on improving the process of problem solving, rather than the syntax of programming and it has great exercises to help do so as well with even simple challenges like Sudoku.

That all said, yes, we all have different learning styles. Head First books may be distracting to Johnny and full-program walkthroughs may not be the way that Sarah learns best, but what I'm talking about here is actually completely orthogonal to learning styles; it actually involves the curriculum content itself... Planning teaching time and lessons specifically dedicated to teaching students to fully understand and solve the problem on paper before coding.

This is not to say that "nobody should ever jump into code first," but rather, students will have the knowledge necessary to effectively work through a comprehensive workflow where needed. A final point as well; we don't need to turn coding lessons into watching paint dry here and we could still have students jumping into code on occasion, but the idea is to plant a seed in their heads that jumping into code isn't often the proper way to solve a real-world problem and that at the end of the day, coding is a tool used to solve real-world problems.

I'd love to hear your feedback and ideas.