Productivity is a huge topic in the software world, in this post I try to capture some of my favourite ways to be a really productive developer.

Context Switching

Avoid context switching as much as possible!
Changing between tasks, answering calls, replying to emails or DM’s and even just “quickly” finding some information for someone that has come over to your desk can cause a context switch.

Whenever a developer switches context they will often have to work back through code in order to work out where they had got too. Even the simple task of switching branch, re building and then having to re-read the ticket can cause delays to the work in progress.

To avoid context switching as much as possible, try to organise meetings so they are grouped together and then block time from your calendar, set your DM status to Busy so that you can get a task or sub task completed within a single session.

Design First

Always design something before implementation, even if its just a small function you are writing adding the comments to the code first can help you speed up the implementation and avoid re working.

• Draw diagrams, maps and high level architecture
• Outline workflows, user flows and data flows
• Document all comments and ideas
• Ask your questions before starting

Once you have designed something you can then show others and get the feedback before spending many hours implementing something that will be thrown back by a design review, QA or worse a product owner during a review at the end of a sprint.

Automate everything

Ok maybe not everything but if you have some tasks that you do repeatedly these could be a great candidate for automation.

Some good examples of things you could automate are

• log mining
• command line combinations
• refactoring
• localization
• building
• deploying
• pre-commit checks such as Linting
• pull requests

The list could go on, its for you to look at what you do on a daily basis

Don’t forget that if you have automated something, share it in the team as others will most likely also have to do the same/ similar tasks. One recommendation is to create a repository for these automations and scripts that can be easily shared and the team can collectively add to it.

Time Blocking

Break up your time into different types of time.

• Creative time
• In the zone coding time
• Downtime
• Meeting time

Its great to block out some time to be creative, lean some new things, try some things out and design your next tasks. However at some point you will need to actually stop being creative and start implementing. The majority of your time should be this in the zone coding time. If you are in the zone don’t stop it for a design session these time blocks can be rearranged when you are on a roll. It is also important to try and block out some meeting time and down time, I also use downtime to clear some emails.

When possible I try to block my day in this order.

• Downtime – clear some emails have breakfast and morning routine
• Meeting time – I try to block these all together, with daily stand-ups and update calls.
• Creative time – a small amount of time to design and try out some new things before implementation starts
• In the Zone Coding time – before Lunch I like to start getting some implementation done, this often moves my lunch based on how in the zone I get.
• Downtime – It is important to break for some lunch! This does move as above.
• In the Zone Coding time – dependant on when lunch happens I will sometimes get going again after lunch but this is often more for testing what was completed prior to lunch.
• Meeting time – to catch people in other time zones.

Extra Principles

Some extra principles I try to work by

DRY – don’t repeat yourself

Twice the amount of work, twice the possible bugs. Don’t repeat fictions that could be used across multiple systems. Add them to libraries or utility code.

KISS – keep it short and simple

Functions should be short and simple in what they are achieving. Someone outside of the codebase should be able to understand it’s inputs and outputs at a glace.

Don’t optimise prematurely

Never optimise to soon, optimisation can take multiple times more work than just getting it working in a sensible manor.

Categories: Productivity

Tags: Automate, code, Design first, Developer, DRY, engineer, KISS, Productivity, Software, Time Blocking