When I first started telecommuting I set up rituals to tell me that I was at work. I would get up, get dressed, head around the corner to a deli to eat breakfast, and return home to my office and that was my "commute" by which I got into the working mindset.
These days, none of that matters. Telecommuting is normal for me and I'm just as effective getting up, grabbing a coffee and heading to the office in my PJs as I was with the whole ritual. What works best for you will depend on your own personality.
However, one thing that I have found extremely important is to not just communicate, but OVERcommunicate. When you meet an important deadline, don't just tell your boss, mention it on the the department-wide mailing list. Chime in on on things like office arrangement discussions where you don't actually care who gets a window or not. The thing is, BE NOTICED. The first time I was telecommuting I learned that half the office thought I had quit, because they never saw or heard from me any more. My collaborators on any given project knew what I was doing, and knew how I was contributing, but no one else did. They weren't blowing my horn, so when raises and benefits came around, they were rewarded but I wasn't.
These days I keep up a steady correspondence with numerous folks at the office and make sure to let everyone know when I think I've done good. In return, there has been much greater recognition of what I've done for the company, and now on the occasions when I actually visit the office, no one says "Who's He?"
I love how the poster saw no need to mention which country or nation was doing this test. Must be Brazil. After all, there aren't any other countries connected to the internet, are there?
The thing is, most folks *live* in reality, and they can not only spot when you have given up attempting it, but it hits them on the head and breaks any verisimilitude you try to put in a game. Like I have had to tell any number of artists hired to do game design, it is FAR easier to write a system that is logical, consistent and simulates (as far as technology allows) reality, and to put in special overrides where something special is supposed to happen, than it is to write something that is designed to be totally 'Hollywood' and surrealistic, and then have to somehow get things like fires and waterfalls and natural phenomena to just 'act like they should'.
Maybe its because the world of programming has changed a lot in the last 20 years, but I fear that, despite my vast experience, I'd fail the HR test mentioned above. I've worked for a lot of small companies in the last 20 years, the vast majority of which have cratered and don't exist any more, so I don't have any existing products or code that I can point to as mine. The few bits that are still around, are covered by NDA, so I'm not at liberty to do more than say "I worked on that." Hardly something that an HR person should simply take my word on. References are also an issue. Do you still have valid contact info for a manager you worked for 7 years ago? For the most part, I don't.
I have contributed to a few open source projects over the years, but its been small patches here and there. Mostly I've been too busy doing paying work to work on stuff for free. This isn't to say that I have an objection to open source work, far from it, but for me being able to put food on the table has always had first priority.
I have run a small personal web server from time to time. Typically I have half-a-dozen different domains hosted on a single server. Things like individual domains for my company, my personal projects, and side projects which aren't yet ready for prime time. With HTTP, this is easy, as one can look at the requested URL when serving web pages and handle any request for any domain that is being supported.
HTTPS doesn't support this. The best you can do is have a single 'main' HTTPS domain, and redirections to other encrypted ports for your second-class domains. Its not pretty.
There is a protocol called HTTP+SSL that would allow multi-hosting, but last I checked it was mostly non-supported.
Its not the speed of the typing that matters, its the cognitive load. If you're spending all of your time trying to remember where the '}' key is, then you'll find it hard to keep your loop invariants invariant in your head. This leads to bugs.
If you type with two fingers, but can do it without looking or thinking about anything other than your code, then it doesn't much matter how fast you go. On the other hand, if you achieve incredibly coding speed by concentrating on your fingers, your code is sure to suffer.
Gah! Would it kill you to let us know what the heck it does?
I agree completely. You think they could at least have copied the first few lines of the Wikipedia article about them:
"Dropbox is a Web-based file hosting service operated by Dropbox, Inc. which uses cloud computing to enable users to store and share files and folders with others across the Internet using file synchronization."
Actually, I'm dealing with just this problem lately. Its not so much that my eyes are going (although now that I'm 45, I find I do prefer larger text) its that I am working on a project that is supposed to be used from across a room. There is a very large set of program in both the Windows and Linux worlds that are incapable of working on a desktop running at 640x480 or even 800x600 resolutions. I've even found ones that can't be used at 1024x768.
One might think that the answer would be to go to a much higher resolution and then tweak all of the various menu- and font-size settings to make things large enough to read. This also doesn't work as those exact same programs often seem to have hard-coded assumptions as to font sizes and one regularly discovers menus which only show the first 3 characters of each entry. Plus, many windowing systems don't seem to provide the kind of user settings needed to configure things for this kind of environment.
While one can (and I do) blame the authors of these program for sloppy coding, there are a very large number of such programs, which can only lead me to think that the OS APIs for handling this stuff in a clean way are far too cumbersome to use correctly.
The first mistake is assuming you have to motivate them. These are creative types. They probably already have all the motivation they need. What you have to do is protect them from the myriad DEmotivational elements of a typical business bureaucracy. That includes arbitrary rules, useless reports, endless meetings, unstable management, constant interruptions, and so on. The list is virtually endless, but just ask your staff and I'm sure they can easily tell you what the most demotivational element is in your office.
Am I the only one annoyed by such an imprecise expression as "1/20th the size". One doesn't know from reading it if this is 1/20th the linear dimensions, or 1/20th the volume. (Turns out its the former, which makes it 1/8000th the volume, which is far more interesting.)
Efficient, bug free code is the Holy Grail of software, and no one has achieved it yet. All I can do is give the standard answers:
1) Nail down the specifications and don't let them change. Once you have a design worked out, any changes to the goal can cause unforseen complications and bugs.
2) Have the system designed by someone with a lot of experience in system design and a proven track record of low-defect designs. Bugs caught and prevented in the design stage are always the cheapest to cure.
3) Take the estimated time for testing and debugging and double or triple it. Cutting time corners is one of the main ways bugs get added or lost. Remember that the really low defect software houses document and justify EVER SINGLE CHANGE TO EVERY LINE OF CODE. This may be overkill for you if you aren't remotely programming a $10 million satellite or writing life-critical code but its how you make sure your defect level is as low as possible.
4) Hire veteran programmers. Its no guarantee of bug-free code, but among better programmers, the longer they've been programming, the cleaner their code is. Besides, they'll know all of these points already. The obvious corollory is not to hire bad programmers, no matter how much experience they have.
5) Turn on all warnings and errors, and use an additional external verifier. I prefer Gimpel Lint, but there are other lints out there as well that can help you. Generally, any tool that can help in the verification process should be used.
6) Code verification walkthroughs. Its amazing how much cleaner folks write code when they know that they will have to show and explain it to a random co-worker.
7) Have unit tests of each module and/or code section as its written. Keep the tests and use them for regression later. Have someone OTHER than the writer of the code test it.
8) Pray to the Deity of your choice that the inevitable bugs won't be serious.
It was an interesting article, but I was surprised to see they named Strategy First (http://www.strategyfirst.com/), a company I helped found, as being Russian.
Strategy First started in Montreal and still has its head office there. Although we have a reputation in Canada as being more socialistic than the States, we're definitely not part of Russia.
I own a 386 SX laptop with 4 Meg of ram and a 60 MB hard drive. When I purchased it second hand, it was possible to install and run Linux and X on it (I used slackware). No Linux distribution I can find today will run on that platform any more, so now it runs DOS.
A friend of mine worked as a security consultant for a firm which shall remain nameless but which handled large amounts of other people's money.
When his contract finished, he told them to change all of his passwords. He ended up checking multiple times over the next six months, and he had to send a number of increasingly irate memos to various higher ups in the company. It wasn't until he mentioned that he still had all the codes to request an armored car full of money to be delivered, no questions, to any address he wanted, that they finally changed his passwords and locked him out.
To this day he doesn't know if they ever made changing passwords a policy, or if he was a special case because he bitched so much.
Put simply Geeks expect to be good at what they do, and they strive to improve if they are not. The fact that you've asked how to be a good manager already puts you ahead of the 80% of the managers that I've met that have never stopped to ask themselves that question.
So, expect that there will be much to learn, and do your best to learn it. Cross check what folks tell you and experiment when necessary. Remember that well over 90% of management theory is nonsense, and you'll have to work to separate the wheat from the chaff.
Oh, and you won't succeed at first, and will have to debug your management systems.
Well, that's just an argument that all website FAQ's should be empty. After all, if it really IS a frequently asked question, you have to wonder why no attempt has been made to ensure that the information is clearly and obviously presented by the website, so that folks have no need to ask the question.
Q: Where can I buy this product in my area A: Etc etc
This is not as useless a FAQ entry as you make it out to be. I can not count the number of times I've visited a website promoting an item that I wanted to buy, and NOWHERE did they mention any method of buying one. No shopping cart, no distributor list, not even a lousy pointer to someone I could ASK these things of.
What you are thinking of is a Dilatant Material: a chemical that changes viscosity under variations of applied force (not temperature). Oobleck (Corn Starch+Water) is the primary exemplar.
I used to always use bob@bob.com, until I learned that my wife's friend owned roo.com and frequently gets mail to kanga@roo.com. It made me stop and hunt around for an address that wouldn't harm an innocent. I finally found it: anything@mouse-potato.com
If you do an nslookup or dig, you'll find that the MX server for mouse-potato is listed as 127.0.0.1, so I've been trying to get it onto as many spammer's lists as I can...
Strange. I'm currently looking for a good IT job and it seems that the only two types that I can find up here in Montreal are ones I'm unqualified for, namely:
1) Sysadmin 2) Web designer
I strongly dislike #1, (nor do I have experience) and I am color-blind and have the esthetic sense of a dead monkey, so #2 is out.
They've been trialing these new parking meters in Downtown Montreal and they are universally hated. The problem is that there is only one 'metering station' PER BLOCK. There is also only a small tag at the parking spot where you want to park that gives the id code for the spot.
This would possibly be exceptable except for all the things that weren't taken into account:
No one wants to walk to the end of the block and back to pay when its 40 degrees below
Parking spots are not clearly marked in downtown montreal, and the presence of a physical parking meter used to be a strong clue that parking is allowed. Now one has to look for little tags that are unreadable from a car, or for the station on the corner to indicate if parking is allowed. Even then, one has to also look for signs that disallow certain spots in the middle of blocks.
Most parking 'spots' are not marked on the streets. There is no point anyway, when snow hides the lines for much of the year. The old meters used to make it clear where the spots were. Now when you finally find a spot and park and walk the block in the freezing cold, you may well find that all spots are already in use, because 11 cars have parked in 10 spaces. Then what do you do? How are the green onions (local metermaids/ticket issuers) supposed to know who to give the ticket to? No one is in their assigned spots!
I think this is yet another case of technology being put in place without any thought to the social and user-interface issues. When are people gonna learn?
Slashdot Mirror
When I first started telecommuting I set up rituals to tell me that I was at work. I would get up, get dressed, head around the corner to a deli to eat breakfast, and return home to my office and that was my "commute" by which I got into the working mindset.
These days, none of that matters. Telecommuting is normal for me and I'm just as effective getting up, grabbing a coffee and heading to the office in my PJs as I was with the whole ritual. What works best for you will depend on your own personality.
However, one thing that I have found extremely important is to not just communicate, but OVERcommunicate. When you meet an important deadline, don't just tell your boss, mention it on the the department-wide mailing list. Chime in on on things like office arrangement discussions where you don't actually care who gets a window or not. The thing is, BE NOTICED. The first time I was telecommuting I learned that half the office thought I had quit, because they never saw or heard from me any more. My collaborators on any given project knew what I was doing, and knew how I was contributing, but no one else did. They weren't blowing my horn, so when raises and benefits came around, they were rewarded but I wasn't.
These days I keep up a steady correspondence with numerous folks at the office and make sure to let everyone know when I think I've done good. In return, there has been much greater recognition of what I've done for the company, and now on the occasions when I actually visit the office, no one says "Who's He?"
I love how the poster saw no need to mention which country or nation was doing this test. Must be Brazil. After all, there aren't any other countries connected to the internet, are there?
The thing is, most folks *live* in reality, and they can not only spot when you have given up attempting it, but it hits them on the head and breaks any verisimilitude you try to put in a game. Like I have had to tell any number of artists hired to do game design, it is FAR easier to write a system that is logical, consistent and simulates (as far as technology allows) reality, and to put in special overrides where something special is supposed to happen, than it is to write something that is designed to be totally 'Hollywood' and surrealistic, and then have to somehow get things like fires and waterfalls and natural phenomena to just 'act like they should'.
Maybe its because the world of programming has changed a lot in the last 20 years, but I fear that, despite my vast experience, I'd fail the HR test mentioned above. I've worked for a lot of small companies in the last 20 years, the vast majority of which have cratered and don't exist any more, so I don't have any existing products or code that I can point to as mine. The few bits that are still around, are covered by NDA, so I'm not at liberty to do more than say "I worked on that." Hardly something that an HR person should simply take my word on. References are also an issue. Do you still have valid contact info for a manager you worked for 7 years ago? For the most part, I don't.
I have contributed to a few open source projects over the years, but its been small patches here and there. Mostly I've been too busy doing paying work to work on stuff for free. This isn't to say that I have an objection to open source work, far from it, but for me being able to put food on the table has always had first priority.
I have run a small personal web server from time to time. Typically I have half-a-dozen different domains hosted on a single server. Things like individual domains for my company, my personal projects, and side projects which aren't yet ready for prime time. With HTTP, this is easy, as one can look at the requested URL when serving web pages and handle any request for any domain that is being supported.
HTTPS doesn't support this. The best you can do is have a single 'main' HTTPS domain, and redirections to other encrypted ports for your second-class domains. Its not pretty.
There is a protocol called HTTP+SSL that would allow multi-hosting, but last I checked it was mostly non-supported.
Its not the speed of the typing that matters, its the cognitive load. If you're spending all of your time trying to remember where the '}' key is, then you'll find it hard to keep your loop invariants invariant in your head. This leads to bugs.
If you type with two fingers, but can do it without looking or thinking about anything other than your code, then it doesn't much matter how fast you go. On the other hand, if you achieve incredibly coding speed by concentrating on your fingers, your code is sure to suffer.
Gah! Would it kill you to let us know what the heck it does?
I agree completely. You think they could at least have copied the first few lines of the Wikipedia article about them:
"Dropbox is a Web-based file hosting service operated by Dropbox, Inc. which uses cloud computing to enable users to store and share files and folders with others across the Internet using file synchronization."
Would that have been too hard?
Actually, I'm dealing with just this problem lately. Its not so much that my eyes are going (although now that I'm 45, I find I do prefer larger text) its that I am working on a project that is supposed to be used from across a room. There is a very large set of program in both the Windows and Linux worlds that are incapable of working on a desktop running at 640x480 or even 800x600 resolutions. I've even found ones that can't be used at 1024x768.
One might think that the answer would be to go to a much higher resolution and then tweak all of the various menu- and font-size settings to make things large enough to read. This also doesn't work as those exact same programs often seem to have hard-coded assumptions as to font sizes and one regularly discovers menus which only show the first 3 characters of each entry. Plus, many windowing systems don't seem to provide the kind of user settings needed to configure things for this kind of environment.
While one can (and I do) blame the authors of these program for sloppy coding, there are a very large number of such programs, which can only lead me to think that the OS APIs for handling this stuff in a clean way are far too cumbersome to use correctly.
The first mistake is assuming you have to motivate them. These are creative types. They probably already have all the motivation they need. What you have to do is protect them from the myriad DEmotivational elements of a typical business bureaucracy. That includes arbitrary rules, useless reports, endless meetings, unstable management, constant interruptions, and so on. The list is virtually endless, but just ask your staff and I'm sure they can easily tell you what the most demotivational element is in your office.
Here's a YouTube video I found about the project:
http://www.youtube.com/watch?v=sP1ia_IY1Zg
Am I the only one annoyed by such an imprecise expression as "1/20th the size". One doesn't know from reading it if this is 1/20th the linear dimensions, or 1/20th the volume. (Turns out its the former, which makes it 1/8000th the volume, which is far more interesting.)
I have to agree. I fell in love with Gimpel lint years ago and now I always suggest it as a useful tool whenever I enter a new coding shop.
I only wish the Linux version was as cheap as the Windows one, so I could afford to buy a copy.
Efficient, bug free code is the Holy Grail of software, and no one has achieved it yet. All I can do is give the standard answers:
1) Nail down the specifications and don't let them change. Once you have a design worked out, any changes to the goal can cause unforseen complications and bugs.
2) Have the system designed by someone with a lot of experience in system design and a proven track record of low-defect designs. Bugs caught and prevented in the design stage are always the cheapest to cure.
3) Take the estimated time for testing and debugging and double or triple it. Cutting time corners is one of the main ways bugs get added or lost. Remember that the really low defect software houses document and justify EVER SINGLE CHANGE TO EVERY LINE OF CODE. This may be overkill for you if you aren't remotely programming a $10 million satellite or writing life-critical code but its how you make sure your defect level is as low as possible.
4) Hire veteran programmers. Its no guarantee of bug-free code, but among better programmers, the longer they've been programming, the cleaner their code is. Besides, they'll know all of these points already. The obvious corollory is not to hire bad programmers, no matter how much experience they have.
5) Turn on all warnings and errors, and use an additional external verifier. I prefer Gimpel Lint, but there are other lints out there as well that can help you. Generally, any tool that can help in the verification process should be used.
6) Code verification walkthroughs. Its amazing how much cleaner folks write code when they know that they will have to show and explain it to a random co-worker.
7) Have unit tests of each module and/or code section as its written. Keep the tests and use them for regression later. Have someone OTHER than the writer of the code test it.
8) Pray to the Deity of your choice that the inevitable bugs won't be serious.
It was an interesting article, but I was surprised to see they named Strategy First (http://www.strategyfirst.com/), a company I helped found, as being Russian. Strategy First started in Montreal and still has its head office there. Although we have a reputation in Canada as being more socialistic than the States, we're definitely not part of Russia.
I own a 386 SX laptop with 4 Meg of ram and a 60 MB hard drive. When I purchased it second hand, it was possible to install and run Linux and X on it (I used slackware). No Linux distribution I can find today will run on that platform any more, so now it runs DOS.
A friend of mine worked as a security consultant for a firm which shall remain nameless but which handled large amounts of other people's money.
When his contract finished, he told them to change all of his passwords. He ended up checking multiple times over the next six months, and he had to send a number of increasingly irate memos to various higher ups in the company. It wasn't until he mentioned that he still had all the codes to request an armored car full of money to be delivered, no questions, to any address he wanted, that they finally changed his passwords and locked him out.
To this day he doesn't know if they ever made changing passwords a policy, or if he was a special case because he bitched so much.
Put simply Geeks expect to be good at what they do, and they strive to improve if they are not. The fact that you've asked how to be a good manager already puts you ahead of the 80% of the managers that I've met that have never stopped to ask themselves that question.
So, expect that there will be much to learn, and do your best to learn it. Cross check what folks tell you and experiment when necessary. Remember that well over 90% of management theory is nonsense, and you'll have to work to separate the wheat from the chaff.
Oh, and you won't succeed at first, and will have to debug your management systems.
I don't think the Myth Busters folks ever figured that anyone would plumb a toilet so that its drain went through a water heater...
I know *I* sure wouldn't have suspected it!
Well, that's just an argument that all website FAQ's should be empty. After all, if it really IS a frequently asked question, you have to wonder why no attempt has been made to ensure that the information is clearly and obviously presented by the website, so that folks have no need to ask the question.
Q: Where can I buy this product in my area
A: Etc etc
This is not as useless a FAQ entry as you make it out to be. I can not count the number of times I've visited a website promoting an item that I wanted to buy, and NOWHERE did they mention any method of buying one. No shopping cart, no distributor list, not even a lousy pointer to someone I could ASK these things of.
> one where supermodels chase after Slashdotters in hopes of learning Linux and having their babies.
I'd buy that novel!
What you are thinking of is a Dilatant Material: a chemical that changes viscosity under variations of applied force (not temperature). Oobleck (Corn Starch+Water) is the primary exemplar.
I used to always use bob@bob.com, until I learned that my wife's friend owned roo.com and frequently gets mail to kanga@roo.com. It made me stop and hunt around for an address that wouldn't harm an innocent. I finally found it: anything@mouse-potato.com
If you do an nslookup or dig, you'll find that the MX server for mouse-potato is listed as 127.0.0.1, so I've been trying to get it onto as many spammer's lists as I can...
Strange. I'm currently looking for a good IT job and it seems that the only two types that I can find up here in Montreal are ones I'm unqualified for, namely:
1) Sysadmin
2) Web designer
I strongly dislike #1, (nor do I have experience) and I am color-blind and have the esthetic sense of a dead monkey, so #2 is out.
This would possibly be exceptable except for all the things that weren't taken into account:
I think this is yet another case of technology being put in place without any thought to the social and user-interface issues. When are people gonna learn?