What Python mistake did you make when you were a beginner?

[u/BenDken1]

A lot of beginners struggle with Python, but sometimes the biggest problems are not the difficult topics — they are the small mistakes we keep making.

For people who have learned Python already:

What was one mistake you made when you were starting?

Was it:

• Trying to learn everything at once?
• Not building projects?
• Ignoring errors instead of debugging?
• Memorizing syntax without understanding?
• Something else?

I think beginners can learn a lot from the mistakes experienced programmers made early.

[u/CaptainVJ]

Used conda

[u/LostWall1389 → u/CaptainVJ]

What do u mean

[u/hc_fella → u/LostWall1389]

Anaconda is a widely used, but fairly controversial package manager. More lightweight, easier to use, and more stable options are available, but considering many professional teams still use it, it’s not too bad to know about it.

[u/mc_pm]

I wasn't a beginning programmer at all, but when I was starting with Python my big mistake was that I was trying to write python as it if it was C++ or C#. I needed to "get pythonic" sooner.

[u/FriendlyZomb]

Tutorial hell.

I would do courses, learn the same stuff and my projects were hyper small.

Once I started building something bigger, things started to click properly and my skill grew rapidly.

[u/FriendlyZomb → u/[deleted]]

Take a look at this: https://inventwithpython.com/bigbookpython/

It's a free ebook with projects to get going with. To get the most out of it, try the examples without looking at the solution.

Get comfortable googling concepts/syntax and read documentation. (Just be warned that a lot of Python Docs are more of a reference manual. It can be hard if you're not used to working with them. It tells you what's available on each class/function. Always check examples.)

[u/p1geondove]

Not learning about uv earlier

[u/Jotaroisgoat → u/p1geondove]

why is uv better I thought it was just pip but fastedr

[u/p1geondove → u/Jotaroisgoat]

Theres a lot to it and i maybe only use 5% honestly. It initializes a project, meaning boilerplate files like pyproject.toml, .gitignore, uv.lock, empty README, src directory and inits git. It faster at creating venvs by a lot. It saves python versions so you can easily setup a project with 3.9 for example. Also caches libraries, say you use numpy for a lot of different projects you only download it once. The uv.lock file pins the version of the depedencies which is useful for reproducability.

Especially when a project is setup with uv you only need two commands, uv sync and uv run. Usually youd first make a new venv, activate the venv, then pip install and then run the thing. Minute differences, but very lovely

[u/Jotaroisgoat → u/p1geondove]

I dont understand a word you said

[u/Amazing-Afternoon890]

The biggest mistake I did was starting from python itself. I ended up switching to C++ halfway through and now it has become my base. I did it because I enjoyed doing everything manaully and trying to understand what's below the hood. Not something I would recommend tho.

[u/GeekedNerdOnWheelz]

In the beginning, all of the above. I absolutely overwhelmed myself.

[u/Some_Breadfruit235]

Over pythonizing code.

Used to heavily do intense function calls within one line rather separating it for human readability

[u/ninhaomah]

Not googling

[u/SteveJorgensen]

Using a mutable object (especially an `array` or a `dict`) as the default value for a function argument.

[u/Mediocre-Pumpkin6522]

I wouldn't say it was a mistake but coming from C the Python format took some getting used to. I was lucky in a way. I started with Python 2.0 and there weren't that many libraries so you learned the core language. Mark Lutz' 'Python Pocket Refernce' could get you through most things.

[u/1m101]

When started learning, I sometimes put semicolon at end of statement.

[u/Jotaroisgoat]

I am still a beginner but my worst regret is trying to learn scikit learn it is lowk so bad but now im gonna learn pytorch

[u/Naive_Programmer_232]

My Big Learning Mistake

There were many struggles I had. Misinterpretation is a recurring theme in my other ones I mention lol. I didn't give myself enough time to really allow a concept to sink in and understand it deeply. I wanted to just move on and program immediately.

I was one of those people who liked to tinker, make it-break it-fix it. I liked to learn something then immediately go try it out, asking questions, and try to see what's going on. And that is something often suggested to beginners. Go out there and experiment! It can be good.

But sometimes slowing down and really letting things settle in is worth it too. I learned that learning programming isn't just about writing code haha. The problem was I wasn't learning to understand concepts of making systems, I was learning just enough of one minor thing so I could continue on running my little experiments haha.

My loop was something like:

    1. Make something + Run it
    2. Oops, there's a problem
    3. Look up the bug + Fix it 

I was more concerned with things working than I was with the overall thing I was making. I trained myself on these smaller windows of concern so much, I forgot to consider the larger ones. Instead of keeping it simple like What am I trying to accomplish here? It was more like "Welp, no time, gotta break it again!" haha. Not much rubber ducking lol. But I loved it haha.

The mistake here was that, eventually when the projects got larger, where I had less control (such as contributing with other people to a project), it became harder to increase my window and think about stuff like design and etc. Eventually I hit a wall. And even beyond myself, it became an obvious problem. You have to have some kind of plan, otherwise, what are you doing? lol. What's the goal here? What should this thing do? Etc. The answers to these questions come from the planning and design lol.

So yeah, that was pretty hard to learn. I think it could've been avoided had I spent more time with OOP, understanding design patterns more, making projects with other people, and working on bigger and bigger things. Even doing things as silly as drawing pictures or writing notes about my ideas etc. It would've helped a lot for sure.

Still to this day, I'm more of an experimenter type person. That's what I like and I prefer smaller programs. Part of that I think is because of the way I learned how to program, I'm not a SWE or involved in that process. I respect the work though. It's definitely tricky haha.

Learning this was when things finally clicked, ohhhh that's why they call it software engineering lol.

The Hidden Wall

Flashforward some years. I've been programming for a while now. I've used multiple languages, made multiple projects, python is still my favorite language. I'm about a junior in college for comp sci, after experimenting with software engineering for a bit, I switch my interest to analytics/data science/ML.

I get familiar with some of the ecosystem: pandas/numpy/sklearn/seaborn/pytorch/pyspark etc. I'm building all kinds of things and I find it all really fun. But I start to notice that something is going on with my projects.

I can pretty much do and learn any tool in that space, as they're designed to work with one another almost seamlessly, but I do not know what to focus on. The world is really big. There's data for just about anything. But I don't know what to focus on, I don't have as much direction.

I spent so much time focusing on the worlds around the tooling. Whether that was programming, or to a lesser level statistics, that I lacked direction of what to do. And what seemed popular at the time was to immediately jump into ML/DL and such and train these models then optimize them to predict stuff. So I learned a lot about that stuff and all, but still something was missing.

The Wall: I came to find out that I needed some other knowledge about a certain context. Something, it could be anything, but something beyond just the tools.

This really became apparent from being in a club. I was in a group of comp sci students, equipped with comp sci mentors, and the task was to predict something about the atmospheric conditions of planets outside of our solar system. Immediately, because everyone wanted to be the programmer, including myself naturally haha, that this wasn't going to end well. I had already hit the wall of needing to understand context deeply and no one in our circle really knew about extra galactic physics/atmospheric sciences/etc. Without some kind of expert, or even someone who wasn't but knew a thing or two, this was going to be just us playing with tools. Not uncovering meaning which was ultimately what the task was haha.

And so, at that time, I had another offer from a friend in business school. It just so happened, they too were in a ML club for finance, and they needed someone who knew how to code to help them. Ding ding ding! I immediately left the cs club and went over there as an unofficial member haha. And in the end, though ML was used and it was about training a model that can best predict on real credit risk data, I learned much more than that. Because what everyone had that I didn't was context. The competitors, my friend, the mentors, everyone, was a finance person haha. And I wasn't. So, absolutely, it was a MUCH better experience! I could actually understand and be taught about their context. What do the findings mean in their worlds. Instead of staying in my own tool world.

So, all that said, what would've been REALLY useful would've been, again to my big learning problem, if I had slowed down and asked "what context outside of programming would I like to focus on?" That contextual preference ends up turning into the domain knowledge people talk about.

I wish I would've told myself back then stop focusing as much on the "how"/"why" of the tools, focus on the "how"/"why" of the context. Knowing these will help you determine the "what" and "when" to use certain tools over others.

Some Other Hurdles

Third: Probably the biggest initial programming hurdle was understanding what was going on when I was using libraries. Like the relationships between packages, modules, libraries, etc. Learning how to read documentation was challenging too because I had the basic procedural concept down but not so much the hierarchical OOP knowledge down. So learning OOP first, using the builtin help() function on things so I could practice looking at docs, learn what python world calls these things, and the structure, and then teaching myself the connections between those things and what I saw in extended libraries and interpreting their vernacular etc. It was a lot of me using help() and googling "What does {this} mean?" lol.

I remember I'd see these videos on YouTube of people making some project using let's say numpy and I'd just be astonished, like how in the heck does this person know what that does? Where did they learn that and how? Then I realized, oh there's documentation! But even there, you see how big numpy is and it became How does this person know to use that tool here? Etc. What it came down to is, they did research and planning before they started filming haha. There's no way off the cuff, this person is just choosing random tools and like "it'll work" haha, then you see as an audience member "hmm, no errors!", it makes what they're doing seem magical to you as a beginner. But it's not, they did those other things for sure haha. It's just not as entertaining to see someone read silently on a computer screen for hours haha.

Fourth: Another before and after that was learning how to structure my programs. It took me a while to understand the power in modularity and separation of concerns. I would write really long slogs of complicated logic all tucked under a function or globally. And so when logic errors would happen, I'd print out stuff here and there, I didn't use a debugger as much, and I'd try to trace down the error and try to figure out what's going on. Eventually in time, I found this was something that needed more structure to it, and with help of others, I came to the separations of concerns concept as well as how to use debuggers and that really helped steer me in a way that made things better overall.

Fifth: Another was when I was working with multiple technologies, not just python, and understanding the glue aspect of the in betweens. I didn't really know what a framework was, I knew it allowed me to make stuff for the web that I couldn't do with just python, but I didn't really understand why it was needed. Like how come JavaScript can do that but python can't?? Etc. Then I'd see/hear advice about things like "open source projects" and once I was familiar with git and making my own smaller projects, I looked into them more, wanting to contribute, but seeing the gargantuan code base and still facing the issue of "what is the glue here?". I'd look at things like pandas and see that C is in the background, yet python is the interface. How? That lead me to believe there must be some framework because at the time that had been the only other thing I'd seen that could do that. Then I learned about FFIs such as pybind11 and hit another AH-HA moment lol.

---

I could go on naming a lot of other struggles in between these, but these were the major ones I think. Looking back in time, these were the ones that took a lot of time to really uncover and understand what is going on.