10

Sometimes, after I finish all my tasks, my boss has no tasks to give me. So I sit and feel bad I'm not doing anything. Additionally, I'm not sure if I can surf the Internet and mind my own business or look busy?

What's the standard thing to do in this situation when I have no tasks from my manager?

jmort253
  • 11,416
  • 5
  • 58
  • 83
nurnachman
  • 923
  • 1
  • 9
  • 14
  • 5
    This question is quite similar to yours: http://workplace.stackexchange.com/questions/3408/should-i-ask-for-work-from-my-team-leader – superM Jan 07 '13 at 14:09
  • 9
    Ask your boss what you are expected to do in down time. – Oded Jan 07 '13 at 14:21

4 Answers4

17

There are a variety of things you could do, I list those that I've thought of below. A combination might be the best way to go.

  • You could develop or improve documentation and/or procedures on how you do your job, how your products are used, etc. This will improve your knowledge of these things and can also please management, as they'll feel more comfortable knowing that someone else could work from this documentation if needed.
  • As alroc's answer says, you can do professional development. This could be self driven training in something you currently do or something you might move into. For example, a software developer could improve his/her knowledge of a development methodology, programming lanugage, or other technology. Or he/she could learn about managerial practices if moving that direction is of interest. This will prepare you for the future (and make you more attractive to other employers).
  • You could look over things in your organization and see if you can improve them. Sticking with the software development example, you could find some code that needs improvement and refactor it. This will make things work better for your organization
  • Learn something about another area of your organization. This will improve your overall/"big picture" understanding of how things work where you work, which can be useful for working through ogranizational problems, getting promotions, etc.
  • Network within your organization, so that you have more people available (and better know who to go to) for help you when you need it.
  • Spend some time mentoring a new person. This will develop an ally for you as well as make your organization better.
  • And, of course, nothing. If you work extra time sometimes, you can view this as downtime to compensate for the extra. If you are concerned about appearances, you could arrive just a little later than normal, take a slightly longer lunch, and leave a little earlier than when you're fully engaged with work. If that's not a concern, take an afternoon off and do something you enjoy. This will help you relax and be better able to work hard when the time comes.
Community
  • 1
GreenMatt
  • 21,414
  • 16
  • 81
  • 122
6

If there is no other work to be done in your department, take the time for "professional development" - learn new skills (or learn your current skills more in depth) to better yourself.

alroc
  • 17,916
  • 8
  • 61
  • 63
  • 5
    Please expand your answer and explain why this is better than other alternatives. One line answers that just say what the answer is are not generally good answers. Even though you may "right" answers that explain why help others understand better and make better decisions when faced with related problems. – IDrinkandIKnowThings Jan 07 '13 at 15:12
6

Offer to help one of your collegues. Workloads aren't always balanced exactly. You don't have to do this all the time and give someone an excuse not to do their fair share of the work. If you are new to the job, it's in your favor to take on more responsibility.

3
  • Improve yourself. Learn the codebase, learn the frameworks it uses, learn the language it's coded in. Learn about other languages and frameworks that are in common use. Learn about hardware; what's the current cutting edge in client workstations, what's the current average computing power of workstations in service? What's the latest in server architecture?
  • Perform general maintenance. If you're a coder, peruse the codebase and do general code reviews. If you come across something nobody's actively developing that you think could be improved, refactor it. I say this assuming that you have a well-covered codebase (unit tests that execute at least 95% of total LOC) and therefore can verify that your refactored version meets all the same functional requirements nas the original. I also assume your codebase is big enough that you can find something to improve that won't subject someone else to PMS (Painful Merge Syndrome) on their next commit. Lastly, I assume you are experienced enough with your codebase and with generally-accepted programming methodologies like GRASP/SOLID that you're refactoring and not "refucktoring".
  • Address your own workspace. Clean your desk, organize materials, etc. A lot of developers value a clean workspace free of distractions, but rarely have the time to actively maintain one. You have said time.
  • Assist your co-workers. If you don't have enough to work on, and someone else has too much, ask if there's something your co-worker can split off and give to you, or if he wants to pair. If you're a junior coder, pairing allows you to pick up new things with a minimum of additional time invested by the person you pair with. If you're a senior, you can spread your knowledge and train those around you to code better by pairing. Be careful not to step on toes; the pair process requires a level of buy-in from all participants and their supervisors, and if that's not there you could be viewed simply as an annoyance.
  • Ask around. If you develop internally, generally you can find things to work on by asking end users of the internal software about the problems they have with it. Gather "requirements" for future revisions, and identify any low-hanging fruit that would provide a significant benefit at little cost.
KeithS
  • 2,163
  • 14
  • 12
  • 2
    Every point in this answer assumes the reader is in software development. I realize the OP's profile says he's in software development, and my own answer uses that as an example in a couple places. However, I think we should keep in mind that this site is supposed to be for all workplaces, not just software shops. – GreenMatt Jan 07 '13 at 18:49
  • Your second point assumes that the OP has the permission.authority to do so. In my organization, I cannot make code changes without an authorized change request originating from a business requirement or mandatory technical environment change. – alroc Jan 08 '13 at 13:47
  • Both of these are correct; I approached my answer from my own experiences. Most of these points can be generalized to apply to anything with the possible exception of performing general maintenance. Re: permission to change the codebase, it totally depends on the environment. In a more traditional development model, where changes require manual testing and so making fundamental skeletal changes for non-billable reasons is frowned on, I totally get it. In a more automated environment, acceptance tests are available to quickly exercise changes, and refactoring for style/structure is encouraged. – KeithS Jul 03 '13 at 18:27