As a developer, I have always struggled to find the right amount of time to spend coding per day to maximize my productivity.
You don't want to code too little, as you leave productive hours on the table. You don't want to code too much, as the time you spend coding tends to get counter-productive after a certain threshold.
Working on Onepixa, an AI based design software, which automatically generates ad designs based on your brand styles, I tried a few methods:
The "Elon Musk" way
You have probably seen these motivational videos: "I worked 100h every week!" etc. etc. But in my experience, working these hours will only lead to burnout and crappy code.
The "Have-a-life" way
A bunch of studies suggest that there is a threshold to the number of hours you can work per week, before becoming unproductive. So you an spend some time, ~8 hours, coding every day, take the weekend off, and be maximally productive. But in my experience, you are wasting a bunch of valuable coding time this way, as 40h per week doesn't exhaust you enough.
The "in between" way
This is how I handle my time today, I code 9 hours every day, by splitting my time into 9 x 1 hours slots, and having breaks between (these range from 10 to 60 minutes for lunch). I do this from MO-FR, on SA I work ~7 hours and take sunday off completely. This method has enabled me to:
What are your experiences?
What works for me is defining my "peak performance hours."
After years of coding (and a bit of writing/designing), I noticed that most days between 10 am and 2 pm, I do my most focused/best work. So I generally plan the most important/difficult coding task in that time and try to do smaller tasks outside of those hours.
I think, on average, I have about six actual work hours in which I code/design/write, and then outside of those hours, I try to do my email, bookkeeping, and other not-so-brain-heavy tasks.
So if I had a day of coding, those 6 hours would be:
Four hours of deep, uninterrupted work. Working on a new feature or figuring out a nasty bug.
Two hours of "easy" bug fixes, implementing some copy changes, and small quality of life changes.
I wrote a little bit about it in one of my blog posts for Remote101. It might be worth checking out. But I can also recommend the book "peak performance" because that's where I got the idea from.
I think I work like this too, I find that I'm usually "on" from 11-4 PM roughly and that after that its all down hill for me when it comes to coding. I can do other other tasks well in the evening, but the morning/afternoon for some reason are when I'm most able to focus on coding, especially if I'm learning a new framework or language. during this time, I might watch a lecture for half of it and then spend the rest of writing code and trying to learn what I heard about, or I will expand on previous days learnings.
I find the number 3 from your post interesting, I may try it, looks like Pomodoro a bit, but with bigger intervals.
For me it's very different from day to day, from codding for:
Of course there are some exception to it, for example when I'm debugging something for around 10 hours and I can't focus on something else until I'm done with that, but other then that, I try to keep it to maximum 6h per day, as I think that's the sweet spot.
It depends on the project currently iam coding 5 to 6 hours per day. Great you have given some suggestions i will definitely follow that