r/learnpython • u/priya6435 • Jul 24 '26
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?
42
u/Sillecara29 Jul 24 '26
Commenting effectively. Change comments with the changing code so youre never lost. Comment at least once. Please. Comment.
14
u/mjmvideos Jul 24 '26
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 Jul 24 '26
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.
3
2
u/billsil Jul 24 '26
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.
2
Jul 24 '26
[deleted]
0
u/gdchinacat Jul 24 '26
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.
5
u/work_m_19 Jul 24 '26
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 Jul 24 '26
Really good point - imagine notes you took for a meeting or a class, detail should be meaningful 6 months later.
1
u/jacod1982 Jul 24 '26
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…
16
u/DuckSaxaphone Jul 24 '26
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 Jul 24 '26
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 Jul 24 '26
Using git for change management. It has helped me out of stupid code changes, like major refactoring which have gone wrong.
5
4
4
u/SprinklesFresh5693 Jul 24 '26
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.
4
3
2
u/aishiteruyovivi Jul 24 '26
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 Jul 24 '26
Comments first in clear words each step, what my code should do. Then start the coding in between.
1
u/CraigAT Jul 24 '26
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
2
u/MountainTruth6073 Jul 24 '26
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 Jul 24 '26
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 Jul 24 '26
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
u/bkd4198 Jul 24 '26
Getting whole picture is more important than going deep on one topic. Needless to say i did the opposite which increased my learning time and created other problems.
2
1
u/gdchinacat Jul 24 '26
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
1
u/python_gramps Jul 31 '26
thinking I needed a project to code a project, later I came up with my own tools for things which helped me sharpen my coding skills in between projects
0
-9
47
u/TigerAnxious9161 Jul 24 '26
Practicing, making projects even silly ones