|
About 6 months or so ago, as a test ("it might work") we gave everyone 3 (large) LEGO blocks.
One green, one yellow, one red (you can guess where this is going)
You stack those, and display them on your desk/monitor/whereever - point being, they should be plain in sight, even from across the office.
If the red LEGO is on top : It's basically "UNLESS IT'S ON FIRE, I DON'T WANT TO HEAR ABOUT IT"
If it's yellow : I *am* busy/working - But It's OK'ish to disturb if you really have to (ie. it won't mean I'll lose 30 minutes getting back into the groove)
If it's green : I'm currently only engaged in doing misc tasks that have probably been procrastinated anyhow (and that I'd prob rather not be doing) I'm up for anything (Only ever had that one once for an hour or two...). AKA feel free to talk to me / ask questions - or tell about your weekend.
This is an incredible simple thing to do at any office - and the amazing thing is (at our office) it bloody works!
Even our most talkative/impulse marketing/sales guys/girls will respect it.
I've seen them get up and move towards a coder, only to spot the red LEGO and turn around and sit back down again.
I've even tried having one of them ignore my red LEGO and start talking to me - For me to simply "pointedly point" at the LEGO stack and they shut up (this has happened only once or twice - in the beginning).
Depending on your office, and the people there, YMMV of course.
For us, it works surprisingly well.
And it's such a simple thing to set up as well (aka. it's worth giving it a shot even if you doubt it'll work - As I did initially...)
|
|
|
|
|
Eddy Vluggen wrote: Most workplaces aren't a democracy, and most of the time a manager wants to be able to "walk in and talk".
So when the manager walks in to chat, say "Hold one sec," save your work and shut down the computer. Then chat with him. It should make the point.
|
|
|
|
|
Or simply put it on your timesheet - "distracted by boss talking about phones, 30min"
|
|
|
|
|
When it gets late, around midnight, I get a clarity of mind and focus that I can't get during daylight hours, even in a dark room. I feel like I could go on for hours, and am able to see endless possibilities. By day, these possibilities are qualified with effort and resources, but late at night, it is only me and the code. I do my brain surgery late at night, couple nights per week, and collaborative work during the day.
|
|
|
|
|
Now, that has a ring of familiarity to it - and I guess this goes for a lot people ...
|
|
|
|
|
i will never cease to be amazed at how special programmers think they are.
do no other jobs require attention and concentration?
|
|
|
|
|
Chris Losinger wrote: do no other jobs require attention and concentration?
Helicopter pilot for example.
Every man can tell how many goats or sheep he possesses, but not how many friends.
Shed Petition[ ^]
|
|
|
|
|
Funny you should mention that.
In a lot of airlines they have a "sterile cockpit" policy that requires both pilots to only talk about the job at hand (getting the plane on the ground) once they go below some nominal altitude, often 10000ft. This is because landing a plane requires intense concentration by both pilots despite all the on-board computer wizardry that's supposed to make it easier. The last few seconds are especially crucial, and distractions in that phase of the flight constitute a real risk. They say there are only two kinds of pilots: those who have landed with the gear up, and those who are going to. Too many pilots have been distracted at the point of putting the gear down and forgotten to do it; staying out of both categories is really hard work requiring constant vigilance.
|
|
|
|
|
Chris Losinger wrote: do no other jobs require attention and concentration?
Most certainly - I've never met a scientist who was required to work in an open office solution. I've met a few that shared an office - but then that's the way they wanted it.
My point is that the most efficient work environment isn't necessarily a fixed thing, it changes depending on circumstances. Neither is this an argument that's only about software development.
|
|
|
|
|
Espen Harlinn wrote: Most certainly - I've never met a scientist who was required to work in an open office solution.
+5
CPallini wrote: You cannot argue with agile people so just take the extreme approach and shoot him.
:Smile:
|
|
|
|
|
Chris Losinger wrote: i will never cease to be amazed at how special programmers think they are.
do no other jobs require attention and concentration?
Do you interrupt a surgeon during work? A policeman during a chase? How productive is a mathematician that gets bombarded with all kinds of information, without being given time to process it?
A civil servant behind a desk, that's one you can interrupt. Interrupting working people simply means that you're interrupting work. Which is allowed, but one would have to accept the logical consequences thereof.
|
|
|
|
|
Strip-club owner? If I owned a strip club, I'd be concentrating very hard anyway.
|
|
|
|
|
Of course us programmers work at night. We sleep during the day, so the only time left to work, is at night.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
Chris Meech wrote: We sleep during the day, so the only time left to work, is at night.
Lucky you
Doesn't work quite like that around here ... joking aside, there are times when that would be the best way to work - thankfully not often, but pretending they don't exist doesn't do an organization much good either.
|
|
|
|
|
Already being discussed in the Insider News[^]
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
With a slightly different spin on the discussion, acknowledging that we do vs this is sometimes a good way to work, with, if managed correctly, benefits for both employer and employee - or at least that's why I brought it up.
|
|
|
|
|
Some very thought-provoking responses there!
|
|
|
|
|
I don't keep all that stuff in my head any more. I've found using UML gets the idea down into an easily retrievable form quickly and I've learned to let go of my ego when it comes to using other people's work. Using design patterns also goes a long way. I think a lot of having to keep abstract systems in your head comes from insufficient planning and an unwillingness to value the work of others, also known as "Not Invented Here":
http://en.wikipedia.org/wiki/Not_invented_here[^]
|
|
|
|
|
jim lahey wrote: I think a lot of having to keep abstract systems in your head comes from
insufficient planning and an unwillingness to value the work of others, also
known as "Not Invented Here"
Only up to a certain level - I think it's safe to say that I have fairly good understanding of patterns and their value
Sometimes you work on stuff that doesn't have an established pattern, or you work with software that's 'Not Invented Here', but still very complex. There are also times when you have to get up to speed on something in a read hurry.
|
|
|
|
|
jim lahey wrote: I think a lot of having to keep abstract systems in your head comes from
insufficient planning and an unwillingness to value the work of others, also
known as "Not Invented Here":
I disagree. In my experience, having to keep the system in my head is required to assess the repercussions of changes I'm about to make. In a perfect world, changes in one part of the system are isolated and don't affect others. I've yet to see any code base retain that original design after a few years worth of added unforseen features and new engineers.
My attitude is that if changes I make unexpectedly break stuff elsewhere, then I ruined the team's productivity because I didn't have a sufficiently extensive mental model to spot that repercussion.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
patbob wrote: My attitude is that if changes I make unexpectedly break stuff elsewhere, then I ruined the team's productivity because I didn't have a sufficiently extensive mental model to spot that repercussion.
This is exactly my point though: I argue that through proper planning, the use of UML and design patterns you can guard against this kind of thing happening because you don't have to hold stuff in your head. It also makes context switching much easier.
|
|
|
|
|
For code bases that are as you describe, you are right. I've never seen a code base that didn't start out this way, but I've also yet to see one stay that way over time.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Because we are some kind of mad scientist that transmute caffeine into code, you don't want to do that at day, do you?
Seriously, i think is more about working without interruptions, and as long as you can have a couple of hours to work non stop, it really doesn't matter if you work at day or night.
|
|
|
|
|
I do it simply because at night there are less worldly distractions and as the writer of the article eluded to, my brain can tunnel vision it's attention.
|
|
|
|
|
Re. crash heli in London.
You know, flying cars ... not such a good idea...
Imagine the carnage if there were hundreds of flying cars in the sky; a rolling car crash is not pretty, but when a crash occurs in the sky, gravity takes its revenge and debris will fall out everywhere and most probably in places where emergency vehicules cannot get to.
Nihil obstat
|
|
|
|