25 Pitfalls When Learning to Program
Tags: programming, howtobecomeaprog, learningtoprogram
Published: 2018-08-28 22:07:26

---
title: 25 Pitfalls When Learning to Program
published: true
tags: Programming,how to become a prog,learning to program,programming
canonical_url: https://programmingzen.com/pitfalls-when-learning-to-program/
---

I’m going to share with you what I see as “25” common pitfalls when learning to program (or working towards mastering programming). Many of these points affect both beginners and professionals alike — myself very much included.

**0.** Forgetting that **programming is all about people**. Yes, the machine will execute your code, but programming is solving problems for people, translating their requirements into code that will be read, maintained, and modified by other people (or yourself down the line).

**1.**  **Not spending enough time programming**. Depending on your job or schedule, you might spend a lot of time on tasks that are related to programming but aren’t actually programming itself.

**2.**  **Stopping at the surface** of a given technology you’re learning. Feeling satisfied with having mastered the basics just enough to get stuff done, without ever exploring further or going behind the scenes all that much.

**3.**  **The Magpie approach** to learning programming. You start learning Rails, half-way through you realize that Phoenix is out there, oh and you need to learn JavaScript so you might as well go with Node.js. But wait... [TJ switched to Go](https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e52b), and hold on… what about Rust? Soon enough your browser history will have, “web development or data science career”, “is Clojure dead?”, “Clojure vs Elixir”, “is Crystal mature enough”, “any good frameworks for Golang”, “Phoenix vs Buffalo” and “Kotlin for web development” all in the same week. :)

**4.** Reading books and watching courses online but **not practicing the skills** presented, therefore quickly forgetting about them.

**5**. **Skipping fundamentals**. So you end up learning about continuation-passing style (CPS) but still can’t do SQL joins without an object-relational mapper.

**6.**  **Not enough patience** or discipline to progress through the learning process and steps required to master any technology.

**7.**  **No clear map or schedule for continuing to learn** through available resources, while you tackle more immediate challenges in your day-to-day programming.

**8.**  **Analysis paralysis**, wasting way too much time choosing amongst various frameworks and libraries (like Angular, React, and Vue), rather than just picking one, using it, and switching to something else only if you actually need to do so. Basically being a [maximizer instead of a satisficer](https://www.psychologistworld.com/cognitive/maximizers-satisficers-decision-making).

**9.** Refusing the polyglot nature of modern-day programming. In most domains, it isn’t reasonable to expect one programming language to be the best fit for every problem. Likewise, **identifying too much as an X or Y programmer**, rather than just a programmer who prefers X or Y.

**10.**  **Fear of experimenting with new technology**. Rather than just reading about certain emerging technologies (e.g., blockchain or [chatbots](https://cognitiveclass.ai/courses/how-to-build-a-chatbot/)), actually firing up a VM to try them out yourself, even if it involves getting your hands dirty with a programming language or API you are not familiar with.

**11.**  **Expecting to know everything upfront**. Being disappointed after finding pointers to the solution via Google, because you didn’t come up with an elegant solution entirely on your own and kicking yourself while thinking, “I should have thought of that myself”.

**12.**  **Not creating many small katas**, exercises, and projects while learning.

**13.**  **Fear of sharing code** with others or getting code reviews, lest you be judged.

**14.**  **Not seeking one-on-one mentorship** from more experienced developers.

**15.** Expecting to learn everything at once with **unrealistic timelines** (e.g., master iOS development in a month).

**16.** For the more entrepreneur-minded, **not exploring cool projects because they don’t have a clear path to revenue generation**.

**17.** Not asking questions for **fear of coming across as stupid** or as more of a newbie than you actually are.

**18.** Feeling like you are not a real programmer if you’re creating apps by gluing high-level libraries together, in a high-level language instead of doing “hardcore” algorithms in more complex languages. I dub this **low-level programming envy**.

**19.**  **Allowing the desire to learn best practices to hinder your ability to grasp the fundamentals** of a given language or technology. For example, feeling like you need to learn a whole book on design patterns or master TDD/BDD before you start creating projects.

**20.** Perfectionism. **Letting perfect be the enemy of good enough.** Never shipping anything, getting stuck in the “final touches” phase. (But balance is important, so don’t ship horribly broken software for the sake of shipping.)

**21.** Related to the previous point, **ignoring the progression: make it work, make it faster, make it clean**. Instead, expecting a polished solution from the get-go. It’s important to accept that the first iteration will be a rough draft to improve upon.

**22.**  **Impostor Syndrome**. Feeling that you aren’t good enough. This is particularly bad if you don’t fit the current developer stereotype, as a lack of role models that you can relate with might mistakenly confirm your doubts. This is part of why women and minorities representation in tech is so key.

**23.** Writing code and learning about programming from books, but **never reading other people’s code**. Open Source gives us an amazing resource that can drastically speed up our understanding of programming and best practices.

**24.**  **Not getting exposed to other paradigms or domains**. If you’re a web developer, not learning about other types of development. If you know Object-Oriented programming, not learning about Functional programming.

**25.**  **Not teaching others what you learn**. Nothing will solidify what you learn as well as trying to explain it to others. Even just studying with the intention of teaching will increase your ability to learn.

There you have it… _25_ pitfalls. Oh, don’t forget off-by-one errors, too. ;)

### Conclusion

All this to say:

> You’re good enough. You can definitely do it. Just watch out for these pitfalls, make a plan, commit to it, then take it one step at the time.

When learning to program (or improving your current mastery of it), I recommend the code/read/teach method. Code one real project, and many small exercises/katas as you learn. Read books but also other people’s code. Finally, teach what you learn online and in person. You don’t need to be an expert to do so.

![Learning to program](https://i0.wp.com/programmingzen.com/wp-content/uploads/2017/11/learning-to-program.gif?resize=701%2C271&ssl=1 "Learning to program")

I hope this is somewhat useful. If it is, feel free to share the link online. It’s a list that I, myself, plan to reread once in a while.

Initially, I shared these thoughts on learning to program as [a series of tweets](https://twitter.com/acangiano/status/928316815876300800), but Twitter’s UI had some issues displaying them as a single thread. So I’m reposting them here as a post.

The post [25 Pitfalls When Learning to Program](https://programmingzen.com/pitfalls-when-learning-to-program/) appeared first on [Programming Zen](https://programmingzen.com).