Well, with no prior job experience I am completely ignorant of how things happen at software companies. I want to know what programmers are made to do when there is nothing to do?

Lets consider Facebook or Twitter. Now it is quite improbable that Facebook people have something or other feature in mind to be implemented. So software developers are quite expected to have some time when there is nothing to do.

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

27

I think its more probable that Facebook has 100s or 1000s of features and bugs waiting for developers to be free to address them
–
jk.Oct 18 '12 at 10:33

13

You are working on a false premise. A developer working for a software company is just like a mechanic working for a car repair shop. If they aren't doing something that brings the company money (directly or indirectly) they are costing the company. If they have spare time then their management isn't doing their job properly
–
ChrisF♦Oct 18 '12 at 10:50

4

@jwenting - Well training should come under "indirectly bringing the company money" - as in making sure your employees are still competent to do their job in 5 years time.
–
ChrisF♦Oct 18 '12 at 11:24

@ShashankJain: The job of a developer consists of solving problems. Better code solves a problem better. By working on their code, they are not "picking some other job", but only doing their actual job.
–
MainMaOct 18 '12 at 10:45

2

I don't agree with your answer. While a project may not be perfect, it isn't always in the employers best interest for you to jump back in and start refactoring and enhancing code will-nilly. Not unless you have been tasked to do so. There are usually specific work flows that should be followed in software development and ignoring them could leave the work in a bad place. Untested? 'enhanced' in the wrong way, implemented with no spec/ba/qa/uat. A messed up project velocity. etc. Sorry for being critical.
–
ArkiliknamOct 18 '12 at 15:36

1

@Arkiliknam Which is why the smarter companies carefully separate their DEV, TEST and PROD environments. DEV for developers to play with (often their local machines). Unstable, poorly documented, and often the source of weird and wonderful ideas. TEST for stuff where the developer has come to management with "I was playing with this in my downtime and now it's used by pretty much every internal user." PROD for "Okay, we tested it and it's stable and awesome. Ship."
–
dewordeOct 18 '12 at 16:08

1

If management want you to activly work on them, then MainMa's answer is perfect. In reality if there is work left to do in it, it will most likely be discussed and okayed and put into what ever SDL proces your working in as management usually likes to keep track of things, and if this is the case, then technically its not free time but allocated work. And sure, if there is a backlog, then there's work to be done. I took the question as free-time == no work to be done on the project now (maybe sprint starts tomorrow), today I'll do some prep, research, spiking, etc instead.
–
ArkiliknamOct 18 '12 at 16:35

1

Testing and documentation are potentially never ending tasks, Even more so than polishing the code. You can always do a better job of hunting down corner cases, see how your rotational integration handles a rattleback, do a better job documenting the design or how to use the product.
–
David HammenOct 18 '12 at 16:52

While I agree with other answerers that in a well running software shop developers should have very little spare time, most of us are not working in perfect companies so this still happens from time to time. From my personal experience, there are two situations when this is likely to happen:

when one just joined the company so (s)he is not really part of a team yet and has no idea what to do and how, and

when a project / release is just finished but the next task is not yet assigned.

The first case is the simplest from the point of view of finding things to do: try to learn as much about your new project and team as possible. The technical difficulty may be that you don't have the tools yet to be very effective. E.g. in one company I joined, we sat for more than a week without a computer :-( So all our team leader could do was to print some docs for us to read.

In the second case, it is often the case that you aren't supposed - or even allowed - to touch code anymore on the project you just finished. Sometimes even the project team is dissolved or reorganized. So, on top of what others already suggested, you may use your free time to

discuss potential new projects,

organize coding workshops / contests within the team,

take off holidays to compensate for possible overtime you put in earlier...

It really depends on personality type of the programmer.
Usually we are paid to do the work and PM's keep us busy. However, there are few periods when you may have some time for re-search and trying new things, before jumping to improve the code base or unit tests.

Given the fact that he/she has a break in his project (daily job), programmer may do the following things:

Some will play games (yuup, some are hard core players :)

Read Forums and blogs (the most useful activity to shrink the technical debt)

However, it's highly unlikely that they'll have nothing to do. There's always bugs to be fixed, new features to implement, new problems to solve.
–
ChrisF♦Oct 18 '12 at 10:49

1

Yes, usually we are paid to do the work and PM's keep us busy. However, there are few periods when you may have some time for re-search and trying new things, before jumping to improve the code base or unit tests.
–
YusubovOct 18 '12 at 10:52

1

That is still work related. You won't be playing games or hiking etc.
–
ChrisF♦Oct 18 '12 at 10:53

It totally depends on the company which employs you. But usually something that benefits the company.

This could be:

researching something relative to the company

working on a spike project for an up an coming implementation

studying a new technology

obtaining a relavent certification that not only benefits you but the company

updating documentation

working as a different role, such as a tester if there is no more development work left

educating others

switching to other projects

refactoring (but only if the project is still open to work on! you dont go around adding new code without telling anyone and then have it released untested!)

aside from that, most of what MainMa answered, but only if the company and project allow for it.

Overall, being proactive. Unless you're not affraid the person who signs your pay-check getting angry when they find you playing a game with the excuse "but I finished my work", which is possible and could even be a reward for your hard work. But it really all depends.

Go and find some unanswered questions on stackoverflow and answer them.

EDIT:
Because of the downvote I'm going to explain this a bit more:
By searching unanswered questions and answering them you will do two good things:

you will help somebody to solve his/her problem

you educate yourself

I think learning is one of the most valuable things a developer can do. So when you have time, why shouldn't you? Of course you should be allowed to do so by your company. You are even free to search for questions, that are related to your recent work. This might help you to solve problems that will come in the future easier or better.

I think @MainMa's answer is good, but it does imply a certain type of organization.

In smaller shops that do agency-type work, there are occasions where developers don't have actual project work. This can be the result of the general traffic in the company, and having projects that aren't quite ready for development, projects out for client review, etc. As a lead developer in a company like this, I don't necessarily want my team touching projects in this case. Assuming you have someone to manage this well, it happens rarely, but it does occur from time to time.

If you don't have an office manager (or interns), all staff have the responsibilities for keeping the office going. In our shop, everyone has a "office job" that takes up an hour or two each week. When I started, my assignment was handling the orders for office supplies. While not "billable", these things need to get done.

Outside of this, when someone has actual downtime, I have my team do directed research. For example.

I saw the Foo project on GitHub. Until the feedback comes in on Bar, see if it is a good fit for future projects.

I will also have people mine recently completed projects for pearls that can be improved upon an reused for future projects.