5

I used to work quite hard for my master thesis and later, as a research assistant at a university. I would always finish my job on time and then go off to do something else. Now that I am working a full time job as a developer, I am having trouble adjusting to a fixed 8 hour schedule .. I sometimes slack off intentionally because I know that if I finish what I am doing fast, I wont have anything left to do and will need to just sit around for 2 hours until it is time to leave. This off course, does not lead to any sort of fulfillment, but sitting around for one or two hours when I feel like leaving is something I have never had to deal with before, and it also tires me mentally.

Is there any way I can convince myself to bite the bullet and work 8 hours, without looking at the clock all the time ?

grasshopper
  • 890
  • 7
  • 13
  • 5
    Instead of sitting around, you can improve your skills. :) – Leri Jan 29 '14 at 12:00
  • 2
    I do that, I read books and stuff, but for some reason, I would be more comfortable doing it at home. When I am at work I feel guilty about doing those things. – grasshopper Jan 29 '14 at 12:02
  • Helpful against guilt _ http://workplace.stackexchange.com/questions/5602/reading-work-related-books-during-work-hours/, http://workplace.stackexchange.com/questions/3408/should-i-ask-for-work-from-my-team-leader-when-the-project-is-almost-complete/ – superM Jan 29 '14 at 12:19
  • 4
    This question appears to be off-topic because it is about personal productivity. – Jim G. Jan 29 '14 at 12:49
  • 2
    This is a great question. Those of us who have made the research assistant/thesis transition into full-time work definitely have a very awkward period of transition. – enderland Jan 29 '14 at 13:10

4 Answers4

18

You don't need to "sit around" for two hours until it's time to leave. Here's a few things you can do instead:-

Let your manager know

It doesn't sound like your manager is used to your work-rate. Take this as an opportunity to impress your new employers. People with a reputation for finishing work ahead of time are valuable - and in software, very rare. Let your manager know that you're free and ready to be assigned your next task.

Alternately you may want to see if you can set up a system where you can "pull" work, rather than have your manager "push" it to you. To start with you can make sure that your manager keeps your to-do list sufficiently long that you never run out, but eventually you might want to influence the working procedures of your workplace towards a more agile approach (where your team has a to-do list, and you grab the item at the top when you're free).

Find ways to generate value yourself

If you think your manager will just give you make-work to get you out of their hair, or if you don't like the sound of asking for more, then why don't you look for some ways you can generate value for the company yourself? See if you can automate a build or a deployment. Introduce a tool to automatically enforce a policy usually checked by hand. There are usually thousands of things that could get done that we never get around to.

Use your judgement, though. You're likely to want to clear this kind of thing with your manager anyway.

Improve your skills

Read a book, explore an API, dig into the source control logs of an open-source component your project uses.

Learn about the domain you're working in. Are there any useful documents on your intranet? Regulations that it would be useful for you to understand?

Good employers will appreciate your initiative, though you may wish to exercise caution before indulging yourself excessively.

Iain Galloway
  • 313
  • 1
  • 10
  • 4
    Refactor stuff: Make things mo' better :D – CMW Jan 29 '14 at 13:07
  • 7
    I'm making some assumptions here, but I generally don't advise novice developers to go on a refactoring spree unless they've got an iron-clad suite of unit tests to hide behind. I've lost count of the number of bugs I've seen introduced this way. – Iain Galloway Jan 29 '14 at 13:10
  • Assuming they are novices and committing directly into master without a branch-review-merge process, that might be problematic, yes. But then that would be true for any work they did. Assuming said process is in place, refactoring sprees would even give way to healthy, productive discussions and code reviews. – CMW Jan 29 '14 at 13:15
  • @IainGalloway - if a novice refactors code and isn't sure it will break production they don't have to check it in or they can start creating a test suite. –  Jan 29 '14 at 14:01
  • @CMW: Are you comfortable assuming said processes are in place when the OP doesn't even have a backlog of work to draw from? Code reviews are notoriously ineffective at spotting bugs introduced by refactoring, while a junior engineer's explicitly assigned tasks are typically (though not always) given appropriate attention in QA. In my experience (on both sides), a refactoring spree would be more likely met with "why are you changing this?". In any case, I'm sure the OP will use good judgement in making their decision :) – Iain Galloway Jan 29 '14 at 15:14
  • My commentary: NEVER ask for more work. I have done this and it usually ends up with me embroiled in other people's stories and I end up looking bad – Code Whisperer Jan 29 '14 at 15:45
  • 3
    @itcouldevenbeaboat: Clearly you've never worked in an agile team :D Also, consider the question linked in the comments on the OP ("Should I ask for work..."), it seems pretty clear to me that you have an obligation as a professional to let your manager know you're free so your next task can be assigned - assuming that you're not equipped to pick one up yourself. A hypothetical dev who just sat around until someone noticed they were open wouldn't last long on my team! – Iain Galloway Jan 29 '14 at 17:32
  • 4
    Any dev who didn't ask for more work when finished is someone I certainly would fire. If I have to monitor them like a 5 year old to make sure they are kept busy, then they are too childish to be working. – HLGEM Jan 30 '14 at 18:21
3

It sounds like there is a systemic problem with how tasks are assigned and received at your company.

I don't know what area you work in, but at least in software there's always something to do to improve the product, the tooling, the documentation or your skills. There are always tasks available. There are several issue tracking/ticketing systems available on the market (many free) which can be filled with tasks and prioritised, allowing people to simply take the next task off the queue. If the queue is empty, we expect people to talk to their supervisors for new work.

If you have no software and can't obtain tasking except at the start of the day, keep a notebook of tasks that will help your company advance. See if any of your colleagues need help.

It's always nice to go home having completed a task and having nothing pending: you get to make a fresh start on something next morning. But with a complex job, it's not always (even rarely) possible; some tasks I've worked on have taken days or weeks of work before they're complete - sometimes before they even show visible progress.

To sum up:

  • Ensure there's a system in place (software or business process) for you to receive new tasks 'on demand', as you complete work. That will make sure you have something to do for all 8 of your daily hours.
  • Develop the mental skill of compartmentalisation, allowing you to pause a task at 5pm and restart it 9am the next morning. Going home with nothing pending is a treat.
  • It varies by workplace, but skills and reading are (should!) be valuable and acceptable.
Faelkle
  • 170
  • 5
2

I would recommend you break up your day. It may seem to drag on if you think of it as "another 3 hours to go", instead plan your day in chunks.

There are so many things we can do as programmers:

  1. Clean out Emails
  2. Help others on SO
  3. Review pieces of current architecture
  4. Take a free online course (related to your current software stack)
  5. Offer to assist someone else with a task
  6. Pair program for a few hours
  7. Go for a walk!

Whatever you do, just don't watch the clock, the day will seem like 20 hours instead of 8!

brwngrldev
  • 540
  • 5
  • 10
  • I shall hide the clock. I am a bit nervous about asking for pair programming, even though I know it theoretically would help me learn from other people - I just think it would be awkward and stressing for them and me (I don't feel like I have such great rapport with people to do this). Maybe I should talk about this with management beforehand. – grasshopper Jan 30 '14 at 09:41
0

You basically have two threads of things you can do when you have nothing else to - germane and anti-germane.

Germane comes from the word "germinate," as in germinates from or is spawned from your day to day work.

Assuming you're a programmer...

Germane Activities

  • Answer questions on StackOverflow
  • Check out JavaScript weekly or other periodicals
  • Check out some JSConf talks on Youtube or talks related to your concentration

Non-Germane Activities

  • Read a book
  • Compose simple musical pieces in your notebook
  • Practice your handwriting
  • Watch an educational documentary

Don't

  • Volunteer to do extra work you weren't assigned. This always ends badly.
  • Refactor code or generally make any improvements (Odds are these will be heartbreakingly crushed by the senior programmer)
  • Idly browse the code or wander the company's intellectual property (the principal of limiting knowledge)

When all else fails, simply pack up and leave early. Send an e-mail if necessary.

Code Whisperer
  • 1,998
  • 12
  • 20
  • Can you explain what you mean by the "principle of limiting knowledge"? It sounds like you're saying "don't learn stuff because then you might get asked to do stuff". – Iain Galloway Jan 29 '14 at 16:18
  • 3
    Isn't volunteering to do extra work a positive thing? If you have the time, energy and desire to do more why not appear "proactive" and ask for more to do? – user1049697 Jan 29 '14 at 16:44
  • 1
    If any of our engineers "packed up and left early" because they'd finished what they were assigned, they would find their accounts cancelled in the morning. – Faelkle Jan 29 '14 at 23:03
  • @IainGalloway Principle of limiting knowledge is a real industry practice which refers to not looking at any company materials unless required. This is used frequently by banks, as a principle to regulate random snooping. – Code Whisperer Jan 30 '14 at 13:33
  • @Faelkle Do send them over to work for me once that happens, I could always use some new men who finish their work well ahead of schedule – Code Whisperer Jan 30 '14 at 13:34
  • 3
    @itcouldevenbeaboat: A google search for the "principle of limiting knowledge" yields exactly six results, of which this page is one. I understand not wanting to snoop (and I certainly understand not wanting to expose information to people who do not need to know!). However, a software engineer needs to know rather a lot about the domain they are building for. – Iain Galloway Jan 30 '14 at 14:12
  • 1
    @itcouldevenbeaboat If the principle of limiting knowledge is part of company policy, the employee should know that. Since there's no indication that the asker works for a bank or in a similarly sensitive environment, I don't think that's good blanket advice. – Kelly Tessena Keck Jan 08 '15 at 20:22