27
How to get coding pleasure time
As you advance your career as a developer your responsibilities change with time. You start as a junior who does what he is told. Changing a label here and there, validating an input and other less complex things. With time you become a senior that designs the architecture of the entire system, educates colleagues, defines the business rules with the stakeholders, reviews the code, deploys and does many other things. As the list grows you have more and more tasks on your shoulders. The time spent on context switching becomes more noticeable and you get less and less time for active development.
While that’s ok because you are doing more “senior” stuff than simple coding you can still do some optimizations of your time and get some time for the coding pleasure. Last year right before the covid lockdowns I became one of the technical leads on a huge project. My coding time went from I code most of the day to I will maybe find some time to code in the afterhours in a matter of days. My responsibilities changed rapidly and covid lockdown didn’t help at all. If I wanted to help the team in the delivery, I had to code (Don’t get me wrong, I love coding), which meant I had to optimize my time management. This is what I've done to get some coding pleasure time.
- Group your meetings
I found that if I put most of my meetings in 2 or 3 days of the week I could get 2 or 3 days to do some coding. While those days packed with meetings are exhausting I found that this is a good sacrifice for me to get 2 or 3 days of peaceful coding.
2. It’s ok to say: “can’t talk right now”
We are experiencing the boom of remote work. While the more experienced developers can compensate the physical absence of colleagues to some degree, they still need to communicate in order to perform their tasks. However, the junior developers cannot compensate for that and they will need support to complete their tasks. All of that means you can expect a significant amount of calls during the day. If you are in a coding session and the call is not about something urgent it’s ok to say: “Can you please call me later while I finish the current task at hand?”
3. You are not needed at every meeting that requires the input of your team
Assuming you are not a one man team you can delegate the meetings to you team members. Everyone from your team knows the project and the plan for it to some degree. Figure out what degree is needed at what meeting and delegate. That will help your colleagues to grow because they will practice communication with business and spread the project knowledge around the team. Plus you will have some time for coding.
- Code review
There are few tools that can make your life easier during the code review. Implementing them will allow you to focus on business and architectural aspects of the code that you are reviewing and possibly reduce the time you are code reviewing.
2. Use linters
Linters will check and possibly fix the coding style of the work done so you don’t have to spend the time on that during the code review
3. Use static analyzers
Static analyzers perform the static analysis and will alert the coder on the suspicious code like some potentially bad comparison or invalid return statement. One less thing to worry about during the code review. Since I am a PHP developer I found PHPStan does the great job for this.
4. Dependency checker
Assuming you are using some kind of layered architecture you want to be sure the boundaries are not crossed illegally. Deptrac did a wonderful job for us.
5. Testing code
Before the automated tests, code needed to be checked manually. While the manual part will never be obsolete because you can never predict every single case the human can produce, automated tests will noticeably reduce your time of testing stories and bugfixes. Automated tests will catch unexpected side effects of your code faster than you can find them by clicking. And E2E testing tools can cover your regression and confirm that you didn’t break something along the way.
6. Automated deployment
We found that deployment to a testing environment took between 15 and 30 minutes of developer’s time. That was the case if everything went right. If he would make a mistake, that time would increase significantly. Automating the deployment removed the possibility of human error and reduced the time needed to one click for deploy and a refresh of the page after 15 minutes to check if everything is ok.
As you grow through your career you will code less and less but that doesn’t mean you can’t grab some time anyway. Some of the development stuff that will reduce the context switching will not only be fun and challenging to implement, but it will also optimize your development process and help your colleagues optimize their time as well. The way you spend your time will dictate how you spend your energy and focus during the day. You have a limited amount of both during the day and if you try to cross that limit on a regular basis you are risking a burnout which is very nasty. Hopefully these tips will help you in burnout prevention.
27