Not Job Related

From SoftwareRenaissance ...

Phew. I'm relieved to hear someone else say that they spend their time at work building interesting software that's not job-related. I've been feeling guilty. and rightly so

Who here has written a program on company time that is not job related? What did it do? What made it interesting?

I like to write gravitational simulations. I wrote my first on the department's only graphics system. I could waste hours watching those dots swoop and zoom around the screen. Then I'd throw another formula or two into the program and watch an hour more.
I wrote a program to learn Pascal on the first Apple II at PriceWaterhouse? consultancy HQ in London in 1981, that I discovered in an unlocked room when I was uncharged for a few weeks. I can't remember what it did but it was interesting. After a year of Cobol most things are. (Next year Smalltalk was more interesting than Pascal but those programs were in my own time.)

"and rightly so"

Why? (not original author). I probably spend 30% of my "working hours" goofing off. I play around with other people's software... I write graphic simulations, games, whatever takes my fancy. Nobody here in management blinks an eye.

Now why do you think they would be like that? I am probably a factor of 3 more productive than anyone else in the building. I feel this is strongly correlated to my ability to stop "working" when it isn't going anywhere and let myself wander. On an average day I probably have two or three really productive (i.e., not email, meetings, etc...) hours in me. On an unusual day, I may have 10+, but you can't force that. The company easily gets their money's worth out of me, so what is the problem?

Depends on what the employment agreement is. If you are a salaried permanent employee, then there is probably nothing wrong with using company time to improve your skills or examine alternative technologies (assuming your managers approve). If you are being paid by the hour, or working as a contractor, then charging for time that is spent in non-job-related activities could be considered fraud.

In SoftwareRenaissance, the writer states that he is spending company time doing things that are not useful to his current employer, but will help in his next job. That doesn't seem ethical or professional to me, but I'm sure others will disagree.

I may disagree, but then again, I may not. It depends on whether he thinks his employer could possibly use whatever it is he's investigating, and on his employer's attitude towards such investigations.

I have had situations where my boss said to me, "I wish our software could do X". It just so happened that a library I had explored a few months earlier did X. When I was investigating that library, I had no idea that my company might really someday need that capability, it was just a cool thing I was spending some time looking at. That employer encouraged such exploration, to a degree. The understanding was that as long as our schedule didn't slip because of our "outside explorations", we were free to devote some of our time to such things. I really loved that job. I've had other jobs where you weren't allowed to work on anything that wasn't on the schedule. Those jobs sucked.

In the former case, exploring things I was not currently using was completely ethical, whether that employer ever used any of the things I investigated or not. In the second, it would not have been.

This is only a matter of concern for captives ("permanent" employees). For consultants and other contracting professionals, the ethic of delivering value for fee and turning in a full day's work is usually quite strong. The aspect of learning all kinds of useful things unrelated to the current assignment is the responsibility of the contract professional, to be done on his time, not the client's.

However, in some cases the two align. There have been gigs for me (and, I'm sure, all contract types) where I was charged with doing research that might help out the client. That research may not have worked out for the client so well, but it sure helped me when I was able to carry that knowledge on to the next client.

Additionally, there may be times when I will do research somewhat afield of the client's immediate needs in order to stem off a problem I see looming on the horizon. My last medical instrument gig was like that; the management was so poor that we simply couldn't make progress. I was researching ways to get the client's act together in management terms when I discovered this Wiki. I spent a lot of billable hours looking at articles on this Wiki instead of writing code, but the net result was that I was able to put together reports on project technical management problems, and their possible solutions, that made those billable hours valuable to the client in the long run.

Unfortunately, none of the people I reported my findings to are still on the project. <sigh> Oh, well.

Compare to PlayHurt