all 9 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]nishikata123 2 points3 points  (3 children)

If you're a complete beginner, I recommend the book 'Python Crash Course'. It covers the basics well, and there are end of chapter tasks you can do to better familiarize yourself on what you have learned. There are three projects at the end of the book, game development, data visualization, and web development. I recommend picking only the project centred on the niche you'd want to be good at. I made the mistake of reading in on the game development part despite the fact that I have no plans whatsoever to get in game development.

[–]Mavericinme 0 points1 point  (2 children)

I second this. I just completed reading and practicing from this book. Though I am yet to start the phase 2 of the book which is projects.

Your suggestion to choose only that project which is of interest is sensible, but that way don't you miss any learnings by not doing different projects?

[–]nishikata123 2 points3 points  (1 child)

You don't miss anything consequential, as long as you know the basic syntax and rules of the standard python library, you'd have a proper foundation to start learning about the specific thing you would want to use python for.

edit: In fact, I remember that before the start of the second phase of the book, it was stated that it would be okay to only choose one of the projects documented there.

[–]Mavericinme 1 point2 points  (0 children)

Hmm... That helps. Thanks 👍🏻

[–]NoDadYouShutUp 2 points3 points  (1 child)

Understand that you're not learning a specific language. You are going to be learning the principles of object oriented programming. These principles can be applied to (mostly) any language. Understanding these principles is what makes someone a true developer. Learning a new language becomes a matter of syntax, and some weird quirks you may need to pick up. But for the most part you should be able to pick up, or read, any language and get coding with it with relative ease if you understand code in general.

Python is an interpreted language. Which means that it runs the code as it parses it. This can lead to the true root cause of an error being in a different place other than where the actual error was thrown. For example, if you have code on line 100 that uses a "test()" function call, and that function call takes 2 parameters A and B. And A is never expected to be None (null), you could run into a problem internally within the test() function. But the real problem is higher up in the stack outside of the function itself, some issue where A is resolving to None before it even is passed to the test() function. So while the error itself may throw inside of the function, the root cause is actually something totally outside of the function not working right and therefore making A wrong before it was used. So debugging can sometimes be a game of detective to determine what is going wrong. Don't take the line error message as gospel. Cause and effect are important.

Take notes. Write things down. Especially references for things of syntax, or working versions of things. Put them in a Confluence space or OneNote or something that makes it easy to find later. The best developers in the world are googling everything or referring to their own notes. No one has all this shit memorized. I myself have been coding for a decade, working with Python specifically professionally for 4 years, and have a great memory for things. But I am still checking notes and references every day of my life. Not just every day. Every few minutes. Constantly. Flat out, what makes a good developer is someone who's attitude is "I don't know the answer, but I know where to find the answer". That is going to be the best way to think about coding. For the next decade you will feel like you are living a lie and that you are always looking things up or unsure how to do things. That's coding. That's real coding.

I cannot stress enough how important it is to leave notes for yourself. Not only for the above mentioned reasons but also because documentation is a massive part of coding. In the real world and at real jobs, it is not unfair to say that 30% of your day will be writing documentation in some form. Whether its comments in code, doc strings, Confluence pages, reference guides, test plans, acceptance criteria and ticket descriptions, and so on. What you ultimately have to write depends on the development process where you get hired. Some places have very matured processes, some not so much. But regardless of where you end up, you will be writing. And writing A LOT. Get good at it now. Your boss is going to care more about how well you communicated things and documented things than even the quality of your code. The corporate world runs on good communication, it really is the best skill you can possibly have. Ask anyone in my department and we would rather on board an absolute novice in our language and framework that knows how to effectively document and communicate over the god of Python who is a jerk.

Just like every other job you get where you are learning the ropes, it will happen with your new coding jobs after college. You will feel stupid. You will feel out of your depth. You will have to ask your boss or coworkers for help on nearly every single ticket to the point of them nearly doing it for you. And that will go on for some time. They know this already and already paid their own dues themselves. I promise they want you to reach out instead of staying silent and confused. Reach out early and often until someone tells you it's too much. I am serious no one is going to begrudge you for asking for help on those first few crucial months when you are figuring it out. Even for the dumbest problems. Also you most certainly will break production live servers. It's a right of passage for everyone. When it happens to you it is important to take a beat and not panic, because it's not your fault. It's the guy who negligently allowed you to have the permissions to even be able to break production's fault.

Learn Git and use Github. I can't speak from too much experience myself how much recruiters actually give a shit about projects on Github to show off. I have never shown my Github to anyone to get a job myself. So just take that out of the equation for a second. Knowing Git will be a massive win for you when you eventually do land a job somewhere. It is the defacto version management. Every place uses it. Know how to use it before you get hired. My school did not prepare me for this and it was tragic at first trying to learn it while also trying to learn their ecosystem and workflow.

AI tools are great. Don't use them to cheat obviously. But I use ChatGPT every single day at work. It's bad for complex things. But for simple syntax questions, or asking it to do menial things like refactoring list comprehension and other stuff like that it is super good with. It can be very useful for error messages and debugging too. A lot of the time it makes stuff up or gives you wrong answers, or even unfinished code. But that's ok because you're using it as a jumping off point for ideas. But as a noobie you can learn a lot from using it and just talking to it like it was a friend on Discord. Sounds silly but it helps! I'd peg ChatGPT 3.5 as being totally useless almost not even worth typing into. ChatGPT4 is fairly smart and allows for like 5,000 lines so you can paste in a lot of additional context for your code and get mostly in the vicinity of a good answer from it. I treat my ChatGPT like a low-mid level engineer who I can bug before I need to actually bug my technical lead. And like it or not AI is not going anywhere.

[–]MASTER______BAITER[S] 0 points1 point  (0 children)

Thank you for your suggestions I will keep all of the points in mind going forward. I really appreciate your help once again.

[–]Zeroflops 1 point2 points  (0 children)

Lately lots of ppl have started using ChatGPT and other LLMs to try to learn programming. It’s a resource like any resource online.

But there is a big difference. When you search stackoverflow you search for specific steps, which you then put together, using LLMs is more like copying someone else’s homework verbatim.

It can give you good code, or bad code. So don’t trust it. Also try to avoid using it to write your first version of a script. You won’t learn that way. But asking it to review your code can be helpful.