Lately I've been feeling like I'm being pulled in different directions. In my company there are a lot of forces demanding my time and I'm having a hard time deciding which direction to focus my energies.

I have the choice of several different coding projects, some of which could demand a lot more work over time, and present unknown challenges.

How do you decide what to work on next in the big picture? Grease the squeakier wheels? Low hanging fruit? (translation: easier projects)

Do you have a system for determining and reaching your goals?

+4  A: 

When I have the choice: whatever seems to be the biggest challenge with the most fun attached.

Fun + challenge = rapid learning, to me.

And sometimes that takes me away from the technical stuff - people can be a fun challenge too.

+1  A: 

When I have a choice about which job to start next I try to find a balance between two things: quick, easy fixes that are highly visible (e.g. fix the non-critical bug that a user has been complaining about) and taking on a project where I can use something I've been learning about. I find if I alternate between those types of jobs I can keep myself and my co-workers happy.


I tend to work on multiple projects at one time, so I will work on a harder project, make some headway, and when I get stuck and need to think about how to do the next part, I will go to some low-hanging fruit, so that I can continue to make headway, as I give my subconscious time to work on the harder problem.

But, it really depends on your priorities. I have never been good at just trying to impress people, so I just quietly go about trying to get work done.

James Black
+2  A: 

Easy: What is the highest and best use of my time.

If I am involved in a project and that isn't the answer to that question, I ask myself why I'm working on it and how soon can I finish it.

+6  A: 

A few of the things I ask that affect what I work on :

Are any of my tasks holding up other developers or keeping other people from being able to do their work? If so, it'll probably get done first.

Do I have any tasks with deadlines coming up? If so, it might be the next candidate to work on, unless I can justify something else being worth the task slipping schedule.

Will work on any of the tasks affect (make obsolete / make easier / make more difficult) any of the other tasks I have? If so, it might get moved up.

Is there a good chance that any of the tasks will change (requirements still not concrete / other tasks out there that might affect it), making time spent on it now likely wasted? If so, it gets moved down.

Are there any things that just really bug me, that I think I can get done before anyone notices that I'm not working on whatever my boss thinks is the highest priority. (which is justified because it'll distract me from thinking about the other things).

Are there any tasks I should work on while things are still fresh in my mind?

... other than that, we go with a combination of whatever sort of fixed deadlines I have, what tasks I have that might be holding up other people, what the boss wants first (I like this boss, and I only have one giving me tasks ... in the past, I'd've answered differently), which ones seem more interesting, which ones I can get done quickly to just get them off the list, etc.

There have been times when I've had more than one manager, and I just had to put everything on a list on a whiteboard, and told them to number them (17 items, which kept growing). Management balked, but I was sick of getting bitched out at meetings week after week with stuff not being done, and having to go through the list of every 'emergency' task I was given. (and being told that any manager in the department was allowed to task me in the case of an emergency ... which was something like 30 people ... and being bitched at when I asked who got to decide if it was an emergency or not.)

+2  A: 

:) On Job i left this decision n my Project Leader and Team Leader, As they know better "What is project priority"

At home, i do where i see fun, learning and challenge

+1  A: 

I'd look at what has the highest priority from management's perspective for an intial prioritizing of upcoming projects. If they are all priority 1 projects, then there are a few other factors that may help my decision:

  1. Do I see how valuable the project will be to the organization? Is this the type of thing that really helps with the competitive advantage that we have?

  2. Does there seem to be a buildup of projects of a specific size? For example, are lots of little projects being ignored for the few really big ones? If so, I may take some of the little ones that may be seen as quick wins that may help my team look good.

  3. Do any of these projects use my strengths? This can be a bit hard to determine but it could help a lot with motivation, at least using the Marcus Buckingham interpretation of a strength.

  4. What teams and structures are in place for the other projects? I don't think I'd want to join a project that looks like a massive train wreck about to happen. Is there enough structure so that I won't go off and do my own thing that may hurt the project's chances of success? Do I believe I could handle working with X using methodology Y and technology Z?

Those are a few of how I'd look at making the decision, along with talking to my manager as part of this is his job, right?

JB King
+4  A: 

I tend to weigh 4 items based on things when deciding what to work on next:

  • Is this item a requirement for something else?
  • Can I work on this item yet (ie, am I waiting on something for it)?
  • How fast/easily can I get this item done?
  • How interesting do I find the work required for this item?
+1: As bad as it sounds, I'll sometimes take the interest I have in the particular piece of work into account when deciding what to do next as well.
+3  A: 

High value + Low risk.

Only go on high value + something with higher risk if you already have a track record in the company / credibility.

+18  A: 
Cool. Looks like Stephen Covey applied to software.
John Lockwood
I can vouch that this works really well, as part of lean or any other methodology. The one thing it can't account for is politics but those things don't tend to have much choice about when you do them..
Jon Hopkins
Some things are impossible to convert into direct monetary value: human life, environment, health, good repute, legal compliance, some are very hard to convert accurately enough to make useful judgements. Cost-benefit (or effort--value) analysis is likely to produce a short-term, “quick win” approach and neglect mid- or long-term strategy or any possible emergence. Unfortunately, it’s seems as one the simplest practical analytical tools for decision making to grasp, explain and use as a justification and hence probably it’s popularity.
Some key things about company identity and strategy, particularly in the field of new product development, cannot be justified in terms of effort and value to customer (a legendary sample would be Google’s “I’m feeling lucky” button: costs millions, but doesn’t add much direct value). Moreover, SO wouldn’t have been created if the decision was made based on effort-value, Experts-Exchange on the contrary would.

If we're talking in a work environment, i go through and just prioritise things - what is mission critical, what is urgent, and then anything else just gets put into the list and it gets done in the order it comes in.

As for picking the next big project at work, i like to do what offers the greatest challenge. I had been working as a developer for a year and i had the opportunity to do some work for a very large company working with some security experts and doing things i'd never done. So i chose that, and it looks great on my resume.

In terms of personal development work (not as in self help), again i'll offer something that challenges me. It's got to be something that i haven't done before. It doesn't matter if someone else has done it - i haven't, and i can learn from that.

In the end, it all comes down to what value it holds for you, and what value it holds for the client. Luckily, i've got a few years of sales experience under my belt as well, so i can easily sell the products i need to to clients.

+3  A: 

I my current team (working on a variety of Business Intelligence software projects), we've recently started adopting a variant of classical "agile" project planning and estimating -- everybody seems to be pretty happy with it so far, including us (developers of different levels of experience), the product managers (highly technical people, typically also with some development experience, but mostly interested in the business side of things), management (pretty technical at the level we report to, but also less-technical, more-businessy directors and VPs), and other stakeholders (users and would-be users of our software). But, of course, it is early times, and we'll adjust as we go along. (In the past few years I used other variants of this in very different application areas, such as cluster management software; but I've often also used more ad-hoc, less-structured approaches).

The outline is as follows. At each iteration (we're currently on 2-week iteration cycles), the PMs choose some "elementary units of business value" that they might like to get from projects in our area -- a typical unit would be one feature, a bug fix, some optimization aspect, etc. In a small meeting with tech leads and one or two senior engineers, each unit is decomposed into engineering tasks (and dependencies among tasks are identified). In a larger whole-team meeting, the relative "cost" of each task (how much time, roughly, it will take to perform that task relative to other tasks) is collectively assessed (we're using completely abstract units of effort we call "points", though I've seen other teams use less abstract units such as "ideal engineering-days"). The costs assessed include unit testing and technical documentation.

The tasks, each with its assessed cost, go on what's called "the backlog" for the team, together with "internal restructuring" tasks (typically refactorings that will deliver no new user-observable plus, but will make further development and maintenance more productive), also with assessed costs and a summary of expected benefits (which must be expressed in ways understandable to the PMs -- fortunately, as I said, ours are highly technical people). A refactoring may also, by engineering team consensus, be deemed a prerequisite of certain business-requested tasks (e.g. "makes no sense to work further on component X until class Y, too large, is properly split, which will take N points").

The PMs now get to order the tasks in the backlog in any way they prefer, based on the business value that completing the units those tasks make up would deliver, subject to the dependency constraints. They have a good idea of roughly how many "points" the team may accomplish in a 2-week iteration (our "velocity") based on past results, so they try to make sure some business-valuable release can be performed at the end of the iteration (as opposed to having many business-valuable thingies "in flight"... but none completed and deliverable to stakeholders yet!-).

The team then devotes about 80% of its time and effort to tackling the top-priority tasks as designed by the PMs (including pair programming some of the time, for particularly urgent tasks or for situations where one team member needs to learn more about some technology or some part of the codebase, and another team member who's an expert in those is available for pairing up with them for a while). The priority order is an important indication, but it's not entirey rigid (e.g. if the top task requires extensive work in Java, and the second one requires it in Python, I may well pick the second one, as my relative productivity will be enormously higher that way -- and vice versa for a team member who's a Java guru, etc etc).

"Priority 0" aka "Code Red" issues may arise at any time, and, if they do, by definition they will take priority over any other task (and be accounted for only retroactively in the planning, to make sure velocity is assessed properly). But, as we do a pretty good job with testing, release engineering, and other quality-assurance practices, those emergencies are fortunately few and far between.

This, plus other "mandatory" ways for engineers to spend their time (training courses, all-hands meetings, quarterly performance self-evaluations and peer reviews, etc), is supposed to account for about 80% of engineers' time -- the remaining 20% being time each engineer should devote to "something completely different" ("blue-sky" exploratory projects, "egineering community" efforts, open-source contributions, etc, etc), not directly related to the projects at hand. Nobody actually measures the hours precisely, but that's still a useful guideline (I keep thinking of ways to make measurement easy and painless that I could implement in my 20% time, to help me allocate time and effort more precisely, but I haven't actually gotten any round tuits yet;-).

Alex Martelli

You should ask yourself a question. Are you pursuing a general IT career path which may or may not include your current company, or, do you intend to have a long career with your current employer?

If you intend to have a succesful IT career moving around differnet employers then, sadly, the most succesful strategy is "buzzword collecting". Identify the current/next big thing and try to get it on your CV. e.g. FInd a trivial AJAX with SOA back end project which may never go to production, this will enhance your value to future employers even if the project had little value to your current temployer.

If you plan on a long career with your current employer, the most succesful strategey would be to align your goals with the business. For instance the most critical project for the business may be upgrading an old unsexy VB/Oracle stock control package to include an ancient EDIFACT interface with a new supplier. If you are seen as a key player in the success of such a project you will rank very highly (and rightly so) in your employers esteem, and your opinions and advice will be taken seriously.

James Anderson
+3  A: 

Easy. I ask my boss.

James Jones
Voted down... it's a fair question and this answer provides no information whatsoever.
My boss knows "the big picture" better than I do and his job is to help coordinate my department in order to maximize our efficiency. When I ask my boss "What should I work on next?", we usually engage in discussion about the status of my current work and he usually is able to give me insight as to what's really important to do and what isn't. I think my answer is, at a minimum, helpful to the OP and I'd appreciate if people didn't keep downvoting my legitimate answer.
James Jones
+1  A: 

Since you didn't specify whether you talk from developer or manager perspective, I'll try to cover both.

Providing a framework for prioritisation of efforts is a management’s direct job. The immediate day-to-day prioritisation may stay with management or be handed over to developers.

The decision who should work on what and when in average company is likely to be perceived as a matter of power, control and prestige by both groups and one who makes the most prioritisation decisions as clearly more important player.

In shrewd companies, however, it is well understood that decisions have several interesting properties:

  • Each takes time and effort to make, which is diverted from doing the actual work.

  • Every decision is a trade off

  • To make a good trade off one who makes the decision needs all the right information in her or his disposal

Subsequently, management doesn’t have all the information to make every decision and nor they likely to have right information to make a good trade off in each case, but developers cannot spend their time doing hundreds of prioritisation decisions per day instead of producing software, nor do all necessary co-ordination.

Hence the solution is for management to create a simple framework for task assessment and prioritisation and hand it to developers who will quickly apply it on case by case basis, filling the gaps. In management lingo such framework is called strategy; it saves time by removing repetitive redundant decision making, gives focus and consistency to the efforts, and provides direction. It should be detailed enough to remove the burden of re-assessing the situation each time, but loose enough to allow developers to make right choices when it matters.

The framework itself may give very straightforward rules for making decisions or, alternatively, provide some analytical methods such as Pareto, SWOT, Cost Benefit, Expected Return analysis or Porter Five Forces etc. However, it is worth keeping the rules simple, unambiguous and as straightforward as possible.

Joel Spolsky made available to the world several very good internal software strategy documents written in plain English. Not all documents are directly to do with developing software (showing that it viable actually to have a different unrelated decision frameworks for various aspects of the company life). Also since the documents are several years apart it’s actually possible to see how these frameworks kept changing to suit the situation:

  1. Fog Creek Compensation
  2. Our .NET Strategy
  3. Set Your Priorities
  4. Fruity treats, customization, and supersonics: FogBugz 7 is here

If you're intrested in choosing what things to work on from a personal point of view one of the best advices around in my opinion is the one given by Paul Graham in his essay "What You'll Wish You'd Known".


If your problem is one of procrastination, then perhaps you need to focus on getting rid of those jobs that you fear tackling most - or at least making some forward progress on them to reduce the stress of considering how far behind you are.

This book, by Mark Forster, provides some good tips.

Failing that, you might want to produce an iteration plan. Let everyone vote for jobs - whatever gets the most gets scheduled right away. that way every stakeholder, including yourself gets some input into scheduling.

Andrew Matthews
+1  A: 

Fundamentally as software developers we are business enablers. Your priorities should be in tandem with business priorities and be pragmatic between quick wins and larger strategic initiatives. Effort and Priority make an excellent matrix in which to score projects taking the least effort/highest priority first.

From the tone of your question it sounds like business priorities are either unclear or there is conflicting direction between stakeholders. This is the place to start and it will make your decisions much easier once it is resolved.


I would ask the boss, if they wont make the decision then I would go for the project which I felt was going to be best for the company, in profit and moral of the team.

If I was torn between too projects i would go for the one that sounds like I can develop my skills more and be interested in most.

If a project sounds exciting I become more driven and determined too :)


Given the nature of your question, I'm assuming this is all work that somebody thinks you should be doing, but there clearly isn't enough time to do it all. Therefore, you are just looking for priority knowing full well that some items are likely not to get done.

  1. Impact/Risk if the item isn't done.
  2. Visibility - Does anybody else really care about this task
  3. Alignment with department goals - weed out things that really aren't your job
  4. Alignment with company goals - weed out things that aren't important to your company's business.
  5. Enjoyment factor
  6. Alignment with career goals - Many people would rank this item significantly higher. Depends how important your career is versus what you do today. I've rank today's enjoyment a bit higher than long term career goals. Some projects may be horrible, but they can move along your career.
Jim Rush

I guess it depends on how much is on the list. If there's a lot of low hanging fruit that's been on the list for a while, it may be worth while to take some time and clean some of it off. That way, there would be less demands on the available time and potentially more time or incentive available to work on the big projects.

Plus it can be cathartic to be able to cross a bunch of stuff off the list.

+1  A: 

You really need to discuss this with the business because only they can tell you what has the highest value to them. After that, I would go after the items that carry the most risk because if something is going to cause a schedule to slip it's best to know early rather than late.

If you're having trouble with what the business priorities - usually caused by being on multiple projects with different stakeholders who all think that their project is the most important - you can try getting both stakeholders in a room to discuss which project is higher priority. Or you could delegate that negotiation to your manager as that is actually his job.

Jeff Hornby
+1  A: 
Pascal Thivent

I will usually start working on a larger project first. Then when I feel I need to step away from it for a bit, usually so I can approach it with a clear mind later, I try to kick out some of the quick one-off tasks or simple projects.

I know that isn't very descriptive, but calling the occasional audible for distraction seems to work out well for me when tackling a big project list.


I tend to look at project from a learner prospective. I tend to choose a project that will help me learn something new, I also look for "cool" and intersting as well.

On tthe other hand you can choose your next project according to where it would lead you. Ask yourself if you have a career goal that project X will help you achieve. Perhaps a high profile project is better then intersting - at least for a short while.

One way to defide is to define several key pints that matter to you (i.e. new technology, intersting etc.) and try to rate each opportunity and see which gets the higher score.

Dror Helper