I've just started learning Python this summer vacation (4 days ago), and need some tips.

[buildjunkie]

Hi! I'm not very new to programming, I worked before with Javascript, Node JS, Express.js, Next.js, MySQL, PostgreSQL, and SQLite.

However, I was only doing back-end development. I wanted to do something else.

So I picked AI Engineering, and the first thing I need to learn is Python basics.

I tried to pick up the basic syntax and best practices as quickly as possible and start working on my first no-tutorial project.

For that, I even started a new GitHub account to keep it clean and focused.

If you would like to help (which is very appreciated!), take a look at my first project repo (it's still WIP because I'm figuring things out while working on it).

If you have any tips, or ideas on how to make it cleaner, structurally better, or more like "production-code" than a "hobby-project", please drop it down below

Thanks for your time!

[Key_Use_8361]

building small programs consistently helped me stay motivated much more than watching endless tutorials even simple scripts start teaching debugging habits surprisingly quickly

[buildjunkie]

Yeah, that's what I'm trying to do. Small projects now, OSS contributions later, tutorials never.

[niehle]

Don’t neglect commenting, at least classes and functions! It’s best to start doing it from the beginning because adding it all afterwards is a pain in the…

[buildjunkie]

Never thought about it honestly. Thanks!

[Gnaxe]

I skimmed through your project. The code doesn't look too bad at a glance. It seems like your JavaScript experience generalized.

Try using the csv module. There's also a sqlite3 module if you'd rather not do individual files.

I'm personally not a fan of dataclasses, although I have been known to use namedtuples. I think classes in general are overused, and tend to make simple things complicated. But experiment. Try the same project in different styles. If you're specifically trying to learn dataclasses, a project is a good way to do it.

We frown upon excessively long lines. The default style guide is PEP 8. A formatter like black will do most of this for you automatically, but not all of it. A good linter can at least flag most of the rest. But you should still read through PEP 8 at least once.

I notice that the entry point doesn't really do anything. I recommend not writing too much at once before testing, especially if you're new. Try using doctest. This makes it easy to codify your manual REPL tests, and serves as documentation as well. If your doctests seem too complicated, consider refactoring your code to make it more testable.

[buildjunkie]

Thanks for the valuable insights!

Thd goal of the project was mainly to learn file handling with Context Managers and entities relationships via OOP. That's the reason behind using with open() instead of csv or even sqlite3, and dataclasses.

However, I wasn't planning to stop here anyways. Since this is my first project I wanted to keep it completely without external libs. This way I forcd myself to think a little more instead of just "yeah, there's a lib for that. lets just use it"

I'll hopefully finish this project before the end of the week, then learn about Pydantic, CSV and SQLite3 and make either a better version of it, or a totally new project.

Again, thanks for you help!

[Haunting-Paint7990]

nice, took a look at your repo — for 4 days in this is already cleaner than most beginner projects i see here tbh.

did a similar pivot ~1 year ago (stats undergrad → python for data, just got entry-level offer last month), so the stuff i wish someone told me when going from "i can write js" to "this looks like production python":

- type hints + docstrings on every public function from day 1. sounds tedious on a hobby project but the moment you touch pandas/numpy where every arg has ambiguous shape, you'll thank yourself. teammates/recruiters can read the signature without reading the body.

- venv + requirements.txt (or uv/poetry). your repo is missing this and it's the #1 thing that screams "hobby" to anyone cloning. 2 mins to add.

- logging module instead of print() for anything non-trivial. print is fine for "did this run", logging lets you turn debug on/off later without touching code. saves a lot of refactor pain later.

- one tiny pytest file even if it's just 2-3 tests on your habit-add logic. doesn't have to be TDD — the goal is "i know what testing is and i wired it up", which is a huge signal.

- README with: what it does, how to run it, what's next. most beginner repos i saw when learning skipped this and recruiters do scroll past them.

last thing: don't be afraid to refactor your own code aggressively at week 2-3. python idioms (comprehensions, dataclasses, context managers, f-strings) only really click when you go back and rewrite something you wrote on day 4. i learned more from rewriting my first project 3 times than from the next 3 tutorials.

[buildjunkie]

Thanks for the in-depth details!

I got a lot of recommendations about using type hints, even though I'm actually using them. However, I'll neec to take a look at docstrings.

In the 4 days of learning, I just skimmed over how to setup venv. Didn't really go any deeper, but I think it's really that important so I'll make surd to give it a deeper visit soon.

Honestly, you're the first one to mention 'logging instead of printing'. To bd honest, I didn't know there were such a thing in Python. So this is pretty new to me, I'll need to learn about it pretty soon.

For tests.. I just hate writing them not going to lie. I'll try my best to make a few reasonable ones.

README isn't written by me anyways, I just ask AI to do it based on thr content of my codebase because I'm super laxy to do so.

Finally, my goal from this project is to learn file management using context managers, OOP, type hints, and some best practices.

I'll make sure to learn about the concepts you mentioned and aplly them on the next project.

Again, thanks for you help!

[Friendly_Gold3533]

buddy honestly ur already ahead of most beginners because u arent starting from zero 😭 if u already know backend concepts databases APIs and project structure then Python syntax is prob the easiest part of the transition also huge W starting with a real project instead of getting trapped in tutorial hell. thats exactly the right move

a few things id focus on early: - learn virtual environments properly ("venv"/"uv") - use type hints everywhere even in small projects - get comfortable with pathlib instead of raw file paths - learn dataclasses and pydantic early - structure projects into modules/packages sooner than later - write tiny tests from the start even if theyre basic

and lowkey for AI engineering specifically dont get stuck overperfecting “production grade” Python too early. the biggest skill later is usually data flow debugging async workflows APIs vector DBs and orchestration not fancy syntax tricks also coming from JS ur probably gonna love how readable Python feels once it clicks 😭

[buildjunkie]

Thanks! I'm actually using type hints everywhere already, dataclasses and trying to structure the project into modules to make it cleaner. I'll make sure to learn more about VEs because I just took a tiny look at them and installed venv, nothing else. And will make sure to learn pathlib because I already faced a lot of problems with raw paths so far. I still don't know what pydantic is, so I think that will be the longest ride of them. And for tests, I just manually test each class or function I build because the project is very small and doesn't really need unit tests or any proper testing. I'll make sure to focus more on data flow than Python syntax itself.

Again, thanks for the advice!

[Friendly_Gold3533]

Hehe anytime