This mindset actively discourages the act of looking up information, which is essential for learning.

Imagine that you’re a web developer working on a project that requires the implementation of SSO/IdP. A voice inside tells you, “I’m a professional web developer. I’m supposed to know how to do this already.”

You might spend hours trying to figure it out entirely on your own instead of taking advantage of all the help you can get. And this further adds to your feelings of inadequacy or your Impostor Syndrome.

I suspect technologies like Copilot and watsonx Code Assistant will really challenge those who struggle with this. Remember, it doesn’t matter if you had to look it up. If you got it done, you got it done. This isn’t the Olympics where outside help disqualifies you. Looking up things is an integral part of being a programmer.

(I readily acknowledge that these tools are useful but still being developed and their suggestions can still be inaccurate or suboptimal, but I think the point stands.)

Embrace the mindset that “it’s okay not to know everything; get it done” and such tools become playgrounds for learning and being more productive. If you take the “I’m supposed to know” approach you’ll just see them as crutches and miss out on their potential. Always watch out for psychological barriers. They can make or break you.

The post I’m Supposed to Know appeared first on Programming Zen.

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, 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.

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), 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.

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, but Twitter’s UI had some issues displaying them as a single thread. So I’m reposting them here as a post. Incidentally, this ends my one-year hiatus from blogging.

The post 25 Pitfalls When Learning to Program appeared first on Programming Zen.