Tips for Better Web Development Productivity

Tim Williams • April 9, 2015

Productivity Chart

Bug lists, feature requests, client calls, meetings, cat videos on Facebook; there are many distractions vying for our attention as Web Developers. With new technologies and frameworks constantly springing up needing to be assimilated into your tool belt, productivity and time management probably are not high on the list of priorities. You’d be surprised how much time you can win back by slightly modifying your development behaviors for a more productive workflow!

Respect Development Modes

Understanding the different modes of the development cycle and applying the proper behaviors to them are key to maximizing your time.

  1. Planning Mode: Planning mode is usually at the beginning of a project or between phase releases depending on the software development strategy being employed. During planning mode you are usually doing a lot of communication to build a plan for the upcoming feature/phase/release. The best tip here is don’t jump the gun! Don’t start making a mental model of the problem you are planning to solve until you have clear marching orders. Don’t make assumptions and put them into code. It helps to be clear, concise and prompt in your communications to prevent mistakes that can cost a lot of time down the line!

  2. Sprint Mode: Once the planning stage is complete it’s time to jump into the deep end and get coding. During sprint mode you should try to limit communication as much as reasonably possible. You have a clear picture of the model to be built, and diagrams on what the end product should look like. Caution: If there is too much ambiguity in your model, you may not be out of planning mode yet. It’s easy for use cases to get overlooked in the planning stage, and it’s your job to point out if you find any loopholes. Otherwise, you should be head down in the code, and out of email and chat as much as possible. It helps if the client, or your supervisor is onboard and understands this mode to help limit the distractions.

  3. Cleanup Mode: Cleanup mode happens after a major release when bugs are recorded and sometimes minor “urgent” feature requests are added. During cleanup mode you should be working through a list of tasks to stabilize the last release. Cleanup mode usually requires more communication than sprint mode, but much less than planning mode. You should treat each bug or feature like a mini sprint. Investigate the problem, plan a solution, sprint to solve the solution, then test and document your patch. Take each item one at a time. It helps if the QA is done in a single session and all bugs/feature requests are recorded on a single list. If that isn’t possible, it is best that at least all new bugs/features get added to a list to be worked from instead of emailed or instant messaged to you if possible. It helps to have your whole team on board and understanding that the more time development spends communicating, the less time they spend solving problems! If you work on a team that does not understand this concept, or cannot for legitimate business reasons follow this, you should try and apply it yourself. When a new bug/feature is communicated to you, respond with a “will do” and add the item to your list. Do not take your focus off the current item, just work down the list one at a time. It’s very tempting to try and solve the problems as they come in, resist this urge.

Having everyone involved in the development process respect the modes can pay huge dividends in productivity over the term of a project. If you can’t get your team onboard, try and at least respect the modes as well as you can!