Better programmers than me can write in essays about walking around with a coffee mug and call it programming. And it's perfectly accepted at a place that knows the business. Or see what Gregory House (TV show "House M.D.") does when he is thinking.

But what about the other places where you are the only programmer?

If you don't stare at boring stuff on the monitor for 8 hours straight, co-workers suspect you being a slacker. Yes, not the managers who see the output. Only the co-workers who see the process and can't relate to this kind of work.

Yesterday I had to explain to a trainee of some other profession that software development is like flying. The explanation from the Hitchhiker's Guide to the Galaxy. I don't think she bought it.


One solution could be this:

During their lunch break get them to do a simple task like as a crossword. Ask them to be conscious of the amount of time they spend reading/writing vs. the amount of time they spend thinking [or looking up the answer]. Tell them that this is exactly the same as the time you spend reading/typing vs. the amount of time you spend thinking and looking up answers.

Better still Sudoku because it can involve hours of trying to figure out where you went wrong and why none of your numbers add up. So while the task itself seems relatively easy, after all, it's just numbers in boxes it can take time. Get them to predict how long it'll take them before they start and see if their prediction is right - guaranteed it won't be. You can hit them with a double whammy for why your time expectations never quite add up either.

This is the only way I can really think of to get them to understand the way engineers work. I see lots of "those types just don't get us types" - people are adaptable, people can understand things if presented in a fashion they can understand, it's just that nobody's ever taken the time to present them with an argument they get.


alt text

Just let your build scripts run, see lots of command lines spewing thousands of useless trace messages, and you're all good...

149 accepted

It's funny you ask this question because just yesterday I had a client blow up at a colleague and I who were discussing Google Analytics and Macbooks. Now this client gets charged for our time and we both exclude such time from our timesheets but such breaks are actually important: you can mentally recharge and it can help to work through problems and so on.

Now I put people into two categories:

  • Process-oriented: these people are concerned with how you do things. Do you turn up for work on time? Is your desk neat? Have you filled out your weekly status report? And so on; and
  • Results-oriented: within reason, these people don't care how you do something, they just care that you do it.

I am firmly in the second category and I have a real problem with people in the first. In my experience, people in the first category seem to suffer from insecurity. It's a fundamental psychological principle that controlling your environment makes you happy and such people, who are faced with something where they feel out of control or don't know how to achieve the best results, resort to controlling their environment by dictating how you do things.

You're right in that this is particularly problematic for non-programmers when dealing with programmers. They often just don't understand what we do and how we do it, like how things can take longer than estimated and so on.

Yesterday's case was even worse because this same guy would sit with a colleague and discuss the house she's buying and other things in the middle of doing his own work (and he's charging his clients for his time and I'm sure he's not charging for such downtime), which I found particularly galling as a real double standard on downtime.

So how do you deal with it? Preventively. Try and associate with results-oriented people by choosing the right job, staying in a good job, leaving a bad one, hiring the right people and so on. There will be a point where you'll simply have to put up with such nitpicking however. You can try and explain how the process doesn't work where you just sit there and stuff happens in some linear fashion but in my experience more often than not non-programmers just don't get it and you're wasting your breath and it'll sound like you're just trying to make excuses for slacking off.

In my case, as a consultant, I'm simply going to finish the current project (which is soon thankfully) and then respectfully decline any future work as I've already got more in the pipeline than I can already do.


Years ago I had a gig writing some "Business Basic" stuffs. I was teamed up with a rather "brilliant" programmer with a strange work flow..

He would sit at his computer.. for half to 3/4's of the day.. and play doom / quake / wolfenstine 3D (he was really into the FPS). when he had enough, He'd fire up the editor and just type. At the end of the day, whatever he wrote.. was gold.

We had a new account manager start with the company that walked in on him playing one morning and in dealing with her, was not very polite.

She complained to the CEO that "one of those programmers isn't doing any work at all but playing those violent video games". To which the CEO replied to her "YOU DIDN'T DISTURB HIM DID YOU!?!?".

The games helped him think. He designed, wrote, tested and debugged all of the code in his head while he was playing. Once he was done, it was just a matter of brain dumping and getting it all out.


Why, leave something verbose running on the terminal, of course.


Here's a solution from commandlinefu.com:

cat /dev/urandom | hexdump -C | grep "ca fe"

It will make some data scrolling off the terminal.

alt text


Take a walk

I've found that it's more the appearance of not "working" than anything else. If I leave my desk for a few minutes and walk around outside no one thinks anything of it. Much different than sitting at your desk looking idle.


How about thinking on the lav (the john)?! Of course it limits you to one thought session a day unless you don't mind people thinking you have diarrhea


Think on paper, i.e., make a note of your mental thoughts. I find diagrams make things a lot clearer for me when thinking anyway, so it's a win-win.


Pull out some paper and scribble technical-looking stuff on it. Then when you're thinking, hold your pen and have one hand on the paper. Occasionally add something to the paper.

If you're working on hard problems, you'll probably need a pen and paper to assist your train of thought anyway.


I honestly don't think you can. Sure, you can "pretend" you're working by scribbling, having technical websites open. But if you're doing that, you're not doing the actual "thinking" bit that gets the work done.

I'd stick to worrying about how you get your work done best and not trying to appear to be working to others. If it matters to them they will know the truth.


Pretending you're working on something that's physical, not mental, is a short term solution, I think.

You'd better teach your co-workers that thinking takes most part of the process of programming. Of course, it's a long term solution that may show no value on the first few weeks - or months - but it will surely pay off.

They'll even leave you alone when they see you're quiet, with a mug of coffee in your hand.

Leave him there, they'll say, he's doing his best.


Why do you even think you need to hide the fundamental part of your job as a programmer, ie thinking, from co-workers?

If a co-worker says "Wow! You really don't seem to do much each day, do you?", just explain, in a good natured way, what you are actually doing when they notice you staring off into the distance.

If they continue to have a problem, WHO CARES! Just let the responsible manager deal with it. Of course this relies on the fact that your output is actually acceptable.

This is exactly how I have dealt with this sitaution myself in the past. If someone just doesn't like you, you are not change their views, but most people are simply curious.

A programmer that believes hiding and being deceptive to colleagues about what it they do, will always have difficulty dealing with non-programmers.


Do you really have to do this (I mean explanations)? I know it's tough times, etc. but think of finding some place else when you can.

According to your question several things are wrong with your place of work:

  1. Other people (including peers) should have implicit respect to what you do;
  2. Other people should not be able to observe you all the time;
  3. You being concerned with what other people think of you is counter-productive;
  4. "Flow" is a critical process for software development and you are clearly in environment that doesn't embrace this process.

Pick up Peopleware by DeMarco and Lister to read about these and other things that define and explain right teams and places to work.


Have your eyes closed and when someone walks up to you, say "Amen".


I recall the movie The Firm when Gene Hackman tells Tom Cruise that if he is even thinking about a client, it's billable time. If it's good enough for a lawyer...


I worked for a couple years for a small company as the sole developer. I know for a fact that they thought I was just slacking off when they'd pass by my door and see me on the internet looking something up, or reading a book like Pragmatic Programmer; and even when I was actually writing diagrams related to the current workload.

In short, I don't think it is possible for someone unfamiliar with programming practices to understand what we do. Anymore than it is possible for someone unfamiliar with engines to see a mechanic just standing there staring under the hood, and understand that the guy is actually working.


What I hate is when people see you browsing the internet and think you're slacking off. A key part of expectations or perception management is to not have your monitor facing a busy thoroughfare. I hate people walking behind me as a general rule anyway.


Program in Java. Then you'll have to do a lot more typing. Or, if you're already programming in Java, well, hmmm...COBOL, maybe?


Get a whiteboard and scribble some ideas on it while you're thinking. I find it helps me structure my ideas better than just walking around while thinking.


I always come running back from the toilet, and say I got a great idea while I was thinking there.

The worst part: it is even true, I just make a show out of it. Do the same with coffee break, just break of mid-phrase if you get an idea etc.


I've seen this one. We have an internal IM system where I work. Last year, word came to us (from our boss, as a friendly warning) that people in other departments were looking at the IM client to see our status (if we were "away" or not) and using that to determine that we were slacking off.

So we set our away timeouts to be very high, so it looks like we're always busy, which we usually are.

Between watching programs run that may take time, reading stuff on screen, talking to other programmers next to you, etc... it can look that way.

I don't worry about, really. That's how I work (and the others around me too). That just the way things work in our department. That metric can work with some jobs (i.e. % of time in a call for a call center employee), but it doesn't work for everyone.

What can you do about it? I wouldn't do much. I like the crossword suggestion above. If you are worried about others opinions, I wouldn't be. If they are complaining/making remarks, you can try being nice (the crossword thing) but if it continues you could simply talk to you manager asking for people to basically be informed "he's doing his job, let him be". It's not the job of the clerk 3 desks over to monitor how hard you're working.

The people who watch this kind of thing are usually the same people who are slacking themselves (or at least worried they are, such as a workaholic).

As long as your boss knows you're doing a good job and doesn't think you're wasting the company's money, you should be fine.


Write your thoughts on a paper, so they see that you are working !


Usually what I do is I'll leave something on my computer screen (query in progress, report, data table, etc.) and i'll play with my rubik's cube while periodaclly looking at the screen.


Sometimes when I have a difficult problem, like everything I've tried just isn't working, I lean back in my chair and close my eyes. Guess what that looks like.


I think it's important to distinguish between accepted forms of "thinking" and less conventional methods like some of the ones above (playing FPS games etc). Most workplaces expect some degree of professionalism, and while playing games might be the most effective method for you, society doesn't generally accept that as professional behaviour (yet ;) ).

Usually I just leave the CLI for a linux server open on one screen - most people see that and run.


If they don't affect your getting a paycheck, what does it matter what they think?


If you're the only programmer in your division, it's a pity. Otherwise you could write mini-documents like a model overview - anything high-level - to help you with your implementation thougts.

  • revise your own thoughts
  • provide a written document as basis for possible "stand-up" reviews with fellow developers
  • aggregate artefacts for later detailed documentation purposes (which mostly are required in not-so agile companies)

You can run your test cases in selenium IDE. x 100


My strategies:

  • Bring up some gnarly code in Emacs, and stare in the general direction of the screen.
  • Take a walk.

The problem with the second approach is that if a thought strikes that requires looking something up, you are often a minute or more away from your workstation. Also, I often bump into someone on the walk I need to talk to. That isn't nessecarily a bad thing, but it doesn't help with the task at hand. Still, you end up learning something that you needed to learn. Consider it a holistic development technique. :-)


I get paid to think. I don't apologize for it. I don't try to hide it.

One might find whiny resentful critics anywhere. Their behavior reflects on them--not on anyone else.

If you are working someplace where your bosses accept the whiny criticism at face value, you are much better off getting fired and going to work somewhere with rational management.


I've never had trouble from management but I've heard a lot of gripes from the low-level people my code supported: They felt I was way overpaid for being a fast typist, especially since I spent most of my time simply looking at the screen rather than typing.

I don't think there's anything that can overcome that level of ignorance.


I don't worry about this that much any more. Someone - especially a non-programmer - will always be around to accuse of you of being a slacker. I just do my job and assume the whiners will shup up when they see my finished product.


Talk to yourself.

When I need a thought break at a client I take a walk to the coffee room for coffee or just water (sometimes I take these breaks ten or fifteen times a day, so I can't have coffee every time). If I'm worried about someone seeing me the hall too much, I make sure to talk through whatever problem I'm working on under my breath. It helps make it clear that I'm thinking, not only walking.

Best if you can stop talking to yourself when you leave work, however.


Sometimes the problem is that other workers get jealous if the programmers get too much leeway. It's that way with telecommuting, too - "How come he gets to work at home and I have to drive to the office? It's unfair!" - and the jealous ones complain a lot. That can be a headache.

And @Tim, whether or not playing Doom is unprofessional is really beside the point. Maybe in your company you couldn't deal with it for various reasons, but it's a matter of process and attitude more than adhering to enforcing "professionalism". (That's often often a euphemism used by poor-to-mediocre managers to try and hammer square pegs into round holes when it would be better (albeit more work) to get the most out of the square pegs in the first place.)

You have to decide what, as a manager, you're comfortable with managing and how much work you're willing to do to work with your people. If the game-playing programmer is hitting his schedule and QA milestones, then it's your job to decide whether it's more valuable to your company's business goals to spend time and energy to make your eccentric employees conform or to work around their eccentricities. But if he is doing the basic job you hired him to do, and his bottom-line work is good, why does it matter how he spends his day?

If, OTOH you hired him and are paying him by the hour rather than by the product he produces then how he spends his time is an issue. But my experience has been that the best programmers (that I have managed) will spend great hunks of time thinking about and planning what they're doing and then doing it rather than feeling that they have to be hitting keys to satisfy keystroke counters.

Having said that, if you're a service organization sending a programmer to a client site and the client is paying by the hour then as manager you need to (a) make sure the programmer understands this and agrees before you send him/her on site, (b) hire a different programmer (who may not be nearly as good) or (c) send a proxy onsite and keep the real programmer in the office.

I'm also a developer who has a not-very-dissimilar style of working - I need to think about things (which looks unproductive when measured by someone who doesn't understand programming), and sometimes I get ideas in the shower at 7:30 in the morning and need to work them through right then to see if they're viable or not. But try to explain to a manager who needs you on four back to back conference calls with product managers that you have had a critical insight and need to work at home for the next four hours so you don't have to interrupt your flow and lose your inspiration and you'll test your working relationship in a big way.

There's cookie-cutter programming which is amenable to an assembly-line management approach and there's creative programming which is not and can be difficult to manage if you're low on flexibility or have process-oriented management you have to report to.