this post was submitted on 19 Jun 2023
7 points (100.0% liked)
Programming
3347 readers
3 users here now
All things programming and coding related. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I'm not much of a programmer. I'm working on an android app for personal use though and for me I treat it like a physics problem.
Break it down into smaller less daunting tasks learn how to do a small piece, practice that a bit, then play with it until I can incorporate it into my app. If I get bored with one part of it I switch gears and work on a different piece.
Breaking it into smaller pieces let's me have a lot of small accomplishments when I learn something new and incorporate it. The small accomplishments give me a good dopamine rush and keep me motivated.
This strategy makes a lot of sense. When you get to a section of the program though that you know you are going to dread, whether it be something with the UI or something in the backend, do you knock off sections of it while working on other parts? Or do you try to get it out of the way as quick as possible? These parts for me tend to be the ones that kill a project.
I'm lucky that for me it's just a hobby so if I get burnt out I can take a break. I don't have deadlines to meet or anything like that. So what I do is usually just quit working on it until I get interested again or the state its in bugs me enough to fix it.
Again I'm not exactly a programmer though and if you do it for a living I suspect it's like anything else where you just suck it up and try to get through it until you get to go home.