Click here to Skip to main content
Click here to Skip to main content

The Hidden Secret to Prioritizing Workload

By , 31 Jan 2014
Rate this:
Please Sign up or sign in to vote.
At times, life can feel like one constant distraction in a room filled with interruptions. Add the extra dimensions of new technologies, constant growth, continual communication, and never-ending deadlines brought on by software development, and a general sense of being overwhelmed or confused is understandable. Questions such as "What should I work on first?" or "Should I stop doing that and fix this?" are common. In these circumstances, asking for help is a great start. Seeking advice from a project manager, development manager, or development lead can help set priority. But what happens when those individuals are not available or are on vacation? Additionally, most would agree that any seasoned developer should establish his/her own personal priority barometer. For those new to programming or anyone who has struggled to strike the right balance, don't worry. There is one simple thing all programmers can do to help prioritize their lives.

Before any priority can be determined and assigned, it's important to have a full understanding of expectations. This should lead to the question, "What's my job? Why am I here?" If there is any amount of uncertainty, take the time to become properly educated. Supporting an existing product, developing new features, or managing a team all have different expectations and, therefore, priorities. This conversation should not be about predefined job descriptions. It's about the real world expectations of day-to-day software development. Don't forget to include areas of personal growth in this dialog, which can range from interpersonal skill refinement to increasing one's technical acumen. The primary goal of this exercise is to understand and embody the true purpose for one's job.

Once this clarity is reached, it's time to begin prioritizing work. Start by placing tasks into one of two buckets: Essential or Secondary. Essential tasks are anything that directly relate to one's purpose. Secondary tasks are still meaningful in their own right but are not part of the core. Be sure to heavily scrutinize anything being placed in the Essential bucket. Don't worry about making mistakes about categorizing work; this happens. Mistakes are an important part of growth. The true loss is if nothing is learned from the misstep. Additionally, the work in these buckets should be part of a constant dialog. This is not a once and done process.

When it's time to get to work, focus on the Essential bucket first. If time allows, move to the Secondary list. As time marches on, items may jump from one list to another and that's completely understandable. As deadlines near or budgets change, the purpose and focus for a job might change. At times distractions or unexpected Secondary work will accidentally take over. Don't get upset or too self critical. As soon as it's recognized, consciously determine when to refocus on the Essential work. This doesn't need to be immediate, but everyone should have a goal in mind. Minor distractions can be a great way to break up the work day. But, when that day ends, it's important that proper strides have been made towards completing the Essential work.

Prioritizing work has many additional layers that aren't being covered here. In reality, most people already have a good sense of priority. The struggle lies in properly distinguishing between the Essential and Secondary work. Maintaining proper focus on the Essential work helps ensure happy projects and happy bosses.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Zac Gery

United States United States
Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling.
Follow on   Twitter   Google+

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Mobile
Web01 | 2.8.140415.2 | Last Updated 31 Jan 2014
Article Copyright 2014 by Zac Gery
Everything else Copyright © CodeProject, 1999-2014
Terms of Use
Layout: fixed | fluid