TL;DR
From what I've seen over time, there's 3 types of functional developers:
- The Morning Daisy
- The Code Junky
- The Nocturnal
The Morning Daisy
The daisies always plan for their mornings because that's when they are most productive. Every device and software is turned to DND mode as they focus on pushing commits and accomplishing tasks in a well lit room. Each task has it's time pocket that must be fulfilled and not extended. Their afternoons usually include reviews, documentations and meetings while their nights include planning for the next day, watching tutorials and playing video games. This nature enables them meet deadlines, exercise and go out on weekends.
The Code Junky
Then comes the code junky. This developer is always programming, and doesn't exactly schedule tasks. They easily fit into highly agile environments and that's probably why they contribute to so many projects. It is very typical of them to have nightmares about pushing buggy commits to production. Their typical week has no weekends, and their year has no days-off. This nature enables them become great assets to their companies in a short time frame but at the expense of a social life, abs and more than 3 working brain cells.
The Nocturnal
Spoiler alert: I was a nocturnal. Now a junky :)
The final type is the nocturnal. We all know who this is. Always sending slack messages at 2am and never replying emails. This type of developer is probably what caused the genesis of communication as a defined software development principle. They ultimately do their core programming in the night time because the day time has a lot going on and also because they see their keyboard backlight better in the night --!important. Typically, their weekends are for personal projects and will always 'get back to you' about a particular request (they never do). This nature enables them accomplish a month's tasks in two nights, avoid physical work engagements and make friends through stackoverflow.
Possible 4th
The possible 4th type of developer is the one that wears the other 3 types depending on accounts receivable and time to deadline. They switch through the core types to advance projects in a certain way. You could call them shape shifters or javascript variables (because they are loosely-typed).
---Give a clap if that amused you ---
Scheduling
Now creating a schedule that works for every type of developer will win you a Nobel Prize and get every MAANG project manager instantly fired. What works for me, certainly doesn't work for the daisy and vice versa. Sometimes the disorganisation is what keeps certain developers alive. Yes, I'm speaking to you that feels weird when you're not worried about an upcoming deadline.
The rise of project management tools is a great step for the development space especially for primarily remote companies, but the gross misconduct going on in the shared calendars will traumatise most of us for a long time. How is a developer expected to be 'In the zone' if that zone is constantly being pinged by google meet/microsoft teams/slack/email notifications? When exactly do we get time to code amidst this myriad of meetings and check-ins and retrospectives and syncs and reviews? How do we maintain productivity and simultaneously reduce over communication?
I haven't lived long enough to have all the answers but I know a few things. The greatest thing I know is the type of developer I am which makes the next section easier. I'll walk you through my top 5 tips:
1. Know the time of day you are most productive
This will allow you to place all your development tasks to that time slot and use the rest of the day for management, clean-ups, reviews and tasks that don't require 100% of your cognitive ability. There's still room for compromise according to company policies/teams with huge time-zone differences but not in a way that rids you of that time slot. A good 4-5 hours of programming is far better than 1-2 hours spread across the day. As a code junky I still seclude a good time slot for code productivity despite programming through the day. In conclusion, during this time slot (indicated on your calendar) you should be completely in the zone.
2. Focus on getting small tasks done first
For every task given, try to break it down to its component level and sort the derived tasks in ascending order (bottom-up approach). This will allow you to get tasks out quicker as well as boost your dopamine to accomplish more tasks. There's nothing like getting bogged down by a task for more than a week. That's a waste of productivity and should never be allowed to happen.
3. Account for research time
If a task requires research, it is always best to conduct that research ahead of your programming time slot and document your findings as you go along. Try to conceptualize how your findings will help with the implementation and what relates best to the task. Shifting research to a programming time slot tends to kill productivity, just like a bug caused by missing a semi-colon.
4. Don't feed into the 'working from home' mentality
Try as much as possible to separate work... from home. Start your day at a consistent time, have a shower, dress up, have breakfast and sit at your desk. Create a routine that helps your brain separate the two environments despite them occuring in the same place (just like your linux and windows environments on the same laptop). It might seem a little less of a tip, but it's what helps me stay in the zone. If I woke up at whatever time each day and worked in my pyjamas then I'd still be accomplishing tasks from Q1.
5. Don't go to bed angry
Anger might be too strong of an emotion but what I'm saying is try to re-calibrate your day in the 15 minutes before you hit the bed. Strong and negative emotions really affect productivity and if not dealt with, these emotions cause irritability and fatigue. Programmers might consider themselves emotionless robots but they're not. Burnout is happening everywhere therefore we need to mitigate it as best we can by letting go of the things we cannot change right before our brains slow down to allow sleep. When you find yourself getting angry about things like how upbeat everyone in the team is or why a team member took a whole 2 minutes to respond to your message, then you're in the red. Activities as simple as breathing exercises and eating ice cream go a long way.
Conclusion
Don't be the "all talk and no work" developer. You have the ability to schedule your time for productivity in your projects (and gigs :) ).