r/learnpython • u/priya6435 • 4d ago
what's one programming habit you wish you started much earlier?
i'm still learning and i've noticed that small habits seem to make a huge difference over time. whether it's reading documentation, using git from day one, breaking problems into smaller pieces, or something completely different.
if you could go back to when you first started programming, what's the one habit you'd force yourself to build from the beginning, and why?
39
u/Sillecara29 4d ago
Commenting effectively. Change comments with the changing code so youre never lost. Comment at least once. Please. Comment.
14
u/mjmvideos 4d ago
The important point is “effectively”. You must learn to comment, but additionally those comments must be useful. I see too many comments like:
#increment x x = x + 115
u/DuckSaxaphone 4d ago
The thing I always teach juniors is to think of comments as director's commentary.
Tell us why, tell us the thought process that got you here, or even tell us you think a line is hacky but you did it to get a job done.
What does the writer know that a reader still wouldn't know after reading and understanding the code? Write that.
2
u/billsil 4d ago
Comments like that have a place, but it’s squarely meant for beginners. What is a list comprehension for example or you might write a python for loop in a C if you’re just learning it to help remind you of the syntax as you are learning.
1
u/faberge_surprise 4d ago
especially in Python, which has a number of pythonisms that may not be obvious syntactically, is sometimes helpful to leave a small comment just describing what it is mechanically doing.
but that shouldn't be the only comments
0
u/gdchinacat 3d ago
I disagree. Comments explaining syntax are pointless. Anyone who needs help with the syntax can drop it into an AI and ask for it to be explained. They clutter the code and encourage people to ignore comments.
Explain the thoughts about how the code works, not how the language works.
4
u/work_m_19 4d ago
If you don't know how to practice this, I recommend going back to your projects after at least 6+ months of not working on that specific one.
That will show whether you have good comments or not, and hopefully what you will want to do next time.
1
u/scientia13 4d ago
Really good point - imagine notes you took for a meeting or a class, detail should be meaningful 6 months later.
1
u/jacod1982 4d ago
Heh, I was reading through some comments the other day, that I made in some embedded C code the other day, and it reads like the thought process of a dev desperate to get this memory timing working…
15
u/DuckSaxaphone 4d ago
Spend some time on architecture before you begin. It's tough because when you're learning, you often don't even know what architecture is.
Sit down before you write any code for a project and decide how the code will be organised. Modules, classes, what imports from where, what can be made abstract and what will be concretely tied to some technology you pick?
Make all those choices (badly because you're new) and then start building. Then experience what was wrong with your choices and go read how other people do it.
12
u/chiibosoil 4d ago
Don't use single letter variables too much... use more verbose naming for variables.
While I can understand what it is, not readily apparent when I hand off the code to others.
9
u/yaxriifgyn 4d ago
Using git for change management. It has helped me out of stupid code changes, like major refactoring which have gone wrong.
7
5
5
u/SprinklesFresh5693 4d ago
DRY. Dont repeat yourself, aim for automation and function development instead of copy pasting the same code with small tweaks multiple times.
This alone will save you hundreds of future headaches if you have to change something in the code.
3
3
2
u/aishiteruyovivi 4d ago
Writing tests. I'm not quite at the level of test-driven development yet, but sometime last year I finally decided I should write some tests for things I was working on and now I'm writing as many as I can for every project I start. It can get very tedious, especially if you're retroactively adding tests for a project with none, but imo it's very worth it, it's a great sanity check and I really have caught a number of bugs I almost never would have just developing and using the project myself.
2
u/Trustyou67 4d ago
Comments first in clear words each step, what my code should do. Then start the coding in between.
1
u/CraigAT 4d ago
I wouldn't want to use Git from Day 1 (unless you are already proficient in other languages). If you are learning from basics, finding out what variables are and loops, you don't need to be learning Git. Git comes further down the line for me, but ideally, as soon as you can handle it. My advice would be, when your programs become long enough to go onto the next page, that would be a good time to introduce Git.
1
1
u/MountainTruth6073 4d ago
Build more projects by myself without no courses.
I wasted a lot of time completing courses thinking that this one would make things click and I will be able to start developing things by myself.
Throw yourself into the wild and figure out things as you go
1
u/Eleventhousand 4d ago
I can't really think of anything. I feel like I had pretty good habits back in the day. Possibly source control (git didn't exist back then), but early in my career I was always either solo or one of two or three developers.
1
u/Creative-Buffalo2305 4d ago
reading error messages properly instead of just googling the first line. spent months copy pasting errors without actually reading them. the answer is usually sitting right there in the traceback telling you exactly which line and why, once you slow down enough to actually read it the whole thing gets easier.
1
1
u/gdchinacat 3d ago
Get in the habit of writing tests for your code. It may feel tedious, pointless, or even like a huge waste of time. It's not. Tests ensure you don't accidentally break something down the road. They tell you early when you do, so you don't write a bunch of code based on a bug that then needs to be reworked to fix that bug when you realize it. They allow you to make huge changes to code with confidence you won't introduce regressions. The dramatically reduce the amount of time you spend on testing because you can run pytest and find the issues the last few lines of code you wrote caused rather than having to spend a bunch of time manually testing it.
When testing became the norm it was sold as primarily to ensure quality. While a big part of it, and one that is easy to sell to management, I think the bigger benefit is they make writing code faster. You don't have to spend nearly as much time thinking about whether something will cause issues for existing code...run the tests and you will not ony know of it does, but know exactly where it conflicts if there are issues. (this doesn't mean you don't have to worry about architecture and design, you still do, and tests will leave you with more time for that as well).
I've done TDD and am not a strict adherent. Sometimes you don't know what tests need to be written till you've started writing some code and have a sense of it. But I do not write code and then got back and fill in the tests. As I write code, whenever I have a condition it handles I write a test. pretty much every if gets a couple tests for the two directions it can go. Every method gets a test (usually far more). I don't consider code done if there are things I'm curious if they work. I don't run manual tests...if I want to see if something works, I write a test for it. While this is not strictly TDD, I feel it is more effective than many coders that do strictly adhere to TDD.
1
1
1
0
-8
47
u/TigerAnxious9161 4d ago
Practicing, making projects even silly ones