1. Seek transparency and understanding with your partners early. Issues get harder as time passes
2. Startup founders work long hours for a reason. There’s more work than there are people. If you’re seeking balance, seek it elsewhere.
3. Bad customers will drain you of passion. Really bad customers will drain you of both passion and profits. Unfortunately, most bad customers will degenerate into really bad customers if you don’t do something about it.
4. If you’re changing direction ften, worry a little. If you’re changing people often, worry a lot.
5. It’s lonely at the top, but even lonelier at the bottom. In the early days of a startup, hardly anyone wants to talk to you (except some desperate vendors).
6. Eventually, your product will need to work and do something useful. No amount of marketing or strategy will get you around this.
7. At the end of each day, ask yourself: “Did the product get better for customers today?”. If you don’t have a good answer, stay up until you do.
8. Until you are profitable, time is working against you. Once you are profitable, time is on your side.
9. Learn to take calculated risks. The market rarely rewards safe bets.
10. To improve the quality of your output, improve the quality if your inputs. Read, converse and connect with the right people.
11. Force yourself to write, as it will force you to think.
12. At least once every year or so, your startup will almost die.
13. The problem you solve should be ugly. The solution you build should be beautiful.
14. Even the most successful startup ideas had 100 reasons not to pursue them. There is no perfect idea.
15. If the pain doesn’t kill you, it just hurts a lot.
16. You choose your destiny, because you choose your team.
17. Be who you are. Do what you love. Join people you like.
Thursday, July 27, 2006
Thursday, July 20, 2006
How to restore a hacked Linux server July 17, 2006
Posted by - Marius - in : Linux, Security , trackback
Every sysadmin will try its best to secure the system/s he is managing. Hopefully you never had to restore your own system from a compromise and you will not have to do this in the future. Working on several projects to restore a compromised Linux system for various clients, I have developed a set of rules that others might find useful in similar situations. The type of hacks encountered can be very variate and you might see very different ones than the one I will present, or I have seen live, but even so, this rules might be used as a starting point to develop your own recovery plan.
In most cases if you have a system compromise at root level, you will hear that you have to fully reinstall the system and start fresh because it will be very hard to remove all the hidden files the attacker has placed on the system. This is completely true and if you can afford to do this then you should do it. Still even in this case the compromised system contains valuable information that can be used to understand the attack and prevent it in the future.
Here is a short overview of the steps that I will present:
* Don’t panic. Keep your calm and develop a plan of actions
* Disconnect the system from the network
* Discover the method used to compromise the system
* Stop all the attacker scripts and remove his files
* Restore not affected services
* Fix the problem that caused the compromise
* Restore the affected services
* Monitor the system
Don’t panic. Keep your calm and develop a plan of actions
Ok. You have just found out that you have to restore a hacked system. My first suggestion is to remain calm. Don’t rush and do something you will regret later. Why? Of course you will have to take action as soon as possible, but you can assume that the compromise is probably active for some time and if you act in second 1 or minute 10 this will probably not make much of a difference. If you have experience with such situations and have a proper plan in your mind, go for it, and don’t waste any time. If not, just relax, take 5 minutes to think about what you should do and how to solve this problem.
Example of bad actions during this time: you will rush and kill all the running scripts the attacker has launched and then have a timeout when you will think what to do next… In this time the attacker might see you have discovered him (for example from his irc bot, etc.) and might become upset and clean up the system for you…
Of course you should not go on with your planned trip and take care of this when you get back, I am just saying to use 5-10 minutes to think on this and develop a short action plan. There should be no timeout in your actions and you should always know what is the next step.
Disconnect the system from the network
This might not always be possible. But if you have physical access to the system or even if you are remotely on a system in a datacenter that provides a way to connect from a console (either a regular remote console, or a KVM, or a DRAC card in Dell servers, etc.), then this should be the next step. Connect to the remote console and bring down the network interface.
If you don’t have a remote console, here are some other ideas: you might be able to rent a KVM for a limited time from your datacenter, or you might have to write some iptables rules to block any kind of access besides your own IP.
After this your system will appear down to everyone, including the attacker that will see that the system is completely down.
Discover the method used to compromise the system
This step in my opinion is the most important one and you should not proceed any further until you have a proper answer to the question: “How did the attacker get in?” This step will be probably the most time consuming as the type of attacks can be quite variate. Still if you don’t find out how the attacker got in, then you will risk that you place the system online and he will be able to compromise the system in a matter of minutes. And this time he might not be so nice and you will not have anything to restore… So even if there is not a general method for this, here are some ideas to get you started:
Depending from what tools you have already configured, you need to identify the files uploaded on the system:
* if you have a system like tripwire configured use it to find out what files where added/changed.
* if you don’t have any such system installed, you might have to use the find command to search for the files newer than x days that were added to the system (also changed files in the respective interval).
Who owns the uploaded files?
* finding out the owner of the files will probably show you what application was used to get in. For example files uploaded as the web user will indicate that the web service was used to get in.
Investigate the uploaded files.
* the files that were uploaded on the system might provide valuable information about the attack. For example the attacker might use the same exploit to attack other systems from your compromised server. This can quickly show you what exploit he is using.
Get as much information from the running scripts launched by the attacker.
* as you have seen I have not recommended to stop yet the running scripts that the attacker might have launched. Why? Because they contain invaluable information to identify the attack. Use lsof on them (lsof -p PID) to see useful details. Where are they located? what user owns them? You might find the source of the attack from this information.
Use Rootkit detection tools.
* you might want to run some rootkit detections tools like rkhunter or chkrootkit to quickly identify common attacks.
Investigate system logs.
* with the information gathered by now you might reduce the size of the log information you have to investigate.
Hopefully you have found the source of the attack by now. Again this is very dependent of the type of attack. The most common one you might see these days is an exploit using a vulnerable web application and an attacker that will launch various scripts (irc bots, scanning tools, attacks on other systems, etc.). Still you might see something different like an attacker not launching any script, loading kernel modules to hide its tracks, to make it more difficult to identify or even see the compromise.
Stop all the attacker scripts and remove his files
Once you have identified the cause of the attack you can safely kill all the running scripts launched by the attacker and remove all his files (save them in a different location for further investigation). At this point we no longer need the scripts running as we got the information we could find from them. The system is still unavailable at this point and no service is available to the world.
Don’t forget to clean-up also the locations that the attacker might have entered to start his scripts on system reboot. Look in init scripts, rc.local, cron tabs for this.
Restore not affected services
Once we know the service used for the attack we can stop it and restore the network connection and all the unaffected services the system might provide. For example if the web server was used to get in, we can stop it, and restore other services like mail, dns, to minimize the downtime of the system.
Fix the problem that caused the compromise
Before starting the service used to compromise the system you should fix the problem so this will not happen again once the service is open to the public… Depending on the problem this might involve: patching a vulnerable daemon, upgrading a vulnerable web application (or temporary disable it), writing some special rulers to block it (for ex. mod_security rules might help in case of no patch available for a web application), etc.
Restore the affected services
Once you have fixed the problem you can restart the service used to get inside the system.
Monitor the system
Now is the time to monitor closely the system and see if the fix you have implemented is working. Most certainly the attacker will try to get in again as he will see he has ‘lost’ the system. If you notice any problem stop the service at once and reiterate again to the step to fix the problem (stop the service, fix it, restore it).
Conclusion
These steps are obviously not usable all the time because of the variety of attacks you might encounter, but they can be used as a baseline to develop your own plan of actions. Again in such situations, keep your calm, don’t rush, and work to restore the system based on a clear set of steps.
If you had similar experiences please feel free to share your own tips to help others that might find themselves in such a situation.
Every sysadmin will try its best to secure the system/s he is managing. Hopefully you never had to restore your own system from a compromise and you will not have to do this in the future. Working on several projects to restore a compromised Linux system for various clients, I have developed a set of rules that others might find useful in similar situations. The type of hacks encountered can be very variate and you might see very different ones than the one I will present, or I have seen live, but even so, this rules might be used as a starting point to develop your own recovery plan.
In most cases if you have a system compromise at root level, you will hear that you have to fully reinstall the system and start fresh because it will be very hard to remove all the hidden files the attacker has placed on the system. This is completely true and if you can afford to do this then you should do it. Still even in this case the compromised system contains valuable information that can be used to understand the attack and prevent it in the future.
Here is a short overview of the steps that I will present:
* Don’t panic. Keep your calm and develop a plan of actions
* Disconnect the system from the network
* Discover the method used to compromise the system
* Stop all the attacker scripts and remove his files
* Restore not affected services
* Fix the problem that caused the compromise
* Restore the affected services
* Monitor the system
Don’t panic. Keep your calm and develop a plan of actions
Ok. You have just found out that you have to restore a hacked system. My first suggestion is to remain calm. Don’t rush and do something you will regret later. Why? Of course you will have to take action as soon as possible, but you can assume that the compromise is probably active for some time and if you act in second 1 or minute 10 this will probably not make much of a difference. If you have experience with such situations and have a proper plan in your mind, go for it, and don’t waste any time. If not, just relax, take 5 minutes to think about what you should do and how to solve this problem.
Example of bad actions during this time: you will rush and kill all the running scripts the attacker has launched and then have a timeout when you will think what to do next… In this time the attacker might see you have discovered him (for example from his irc bot, etc.) and might become upset and clean up the system for you…
Of course you should not go on with your planned trip and take care of this when you get back, I am just saying to use 5-10 minutes to think on this and develop a short action plan. There should be no timeout in your actions and you should always know what is the next step.
Disconnect the system from the network
This might not always be possible. But if you have physical access to the system or even if you are remotely on a system in a datacenter that provides a way to connect from a console (either a regular remote console, or a KVM, or a DRAC card in Dell servers, etc.), then this should be the next step. Connect to the remote console and bring down the network interface.
If you don’t have a remote console, here are some other ideas: you might be able to rent a KVM for a limited time from your datacenter, or you might have to write some iptables rules to block any kind of access besides your own IP.
After this your system will appear down to everyone, including the attacker that will see that the system is completely down.
Discover the method used to compromise the system
This step in my opinion is the most important one and you should not proceed any further until you have a proper answer to the question: “How did the attacker get in?” This step will be probably the most time consuming as the type of attacks can be quite variate. Still if you don’t find out how the attacker got in, then you will risk that you place the system online and he will be able to compromise the system in a matter of minutes. And this time he might not be so nice and you will not have anything to restore… So even if there is not a general method for this, here are some ideas to get you started:
Depending from what tools you have already configured, you need to identify the files uploaded on the system:
* if you have a system like tripwire configured use it to find out what files where added/changed.
* if you don’t have any such system installed, you might have to use the find command to search for the files newer than x days that were added to the system (also changed files in the respective interval).
Who owns the uploaded files?
* finding out the owner of the files will probably show you what application was used to get in. For example files uploaded as the web user will indicate that the web service was used to get in.
Investigate the uploaded files.
* the files that were uploaded on the system might provide valuable information about the attack. For example the attacker might use the same exploit to attack other systems from your compromised server. This can quickly show you what exploit he is using.
Get as much information from the running scripts launched by the attacker.
* as you have seen I have not recommended to stop yet the running scripts that the attacker might have launched. Why? Because they contain invaluable information to identify the attack. Use lsof on them (lsof -p PID) to see useful details. Where are they located? what user owns them? You might find the source of the attack from this information.
Use Rootkit detection tools.
* you might want to run some rootkit detections tools like rkhunter or chkrootkit to quickly identify common attacks.
Investigate system logs.
* with the information gathered by now you might reduce the size of the log information you have to investigate.
Hopefully you have found the source of the attack by now. Again this is very dependent of the type of attack. The most common one you might see these days is an exploit using a vulnerable web application and an attacker that will launch various scripts (irc bots, scanning tools, attacks on other systems, etc.). Still you might see something different like an attacker not launching any script, loading kernel modules to hide its tracks, to make it more difficult to identify or even see the compromise.
Stop all the attacker scripts and remove his files
Once you have identified the cause of the attack you can safely kill all the running scripts launched by the attacker and remove all his files (save them in a different location for further investigation). At this point we no longer need the scripts running as we got the information we could find from them. The system is still unavailable at this point and no service is available to the world.
Don’t forget to clean-up also the locations that the attacker might have entered to start his scripts on system reboot. Look in init scripts, rc.local, cron tabs for this.
Restore not affected services
Once we know the service used for the attack we can stop it and restore the network connection and all the unaffected services the system might provide. For example if the web server was used to get in, we can stop it, and restore other services like mail, dns, to minimize the downtime of the system.
Fix the problem that caused the compromise
Before starting the service used to compromise the system you should fix the problem so this will not happen again once the service is open to the public… Depending on the problem this might involve: patching a vulnerable daemon, upgrading a vulnerable web application (or temporary disable it), writing some special rulers to block it (for ex. mod_security rules might help in case of no patch available for a web application), etc.
Restore the affected services
Once you have fixed the problem you can restart the service used to get inside the system.
Monitor the system
Now is the time to monitor closely the system and see if the fix you have implemented is working. Most certainly the attacker will try to get in again as he will see he has ‘lost’ the system. If you notice any problem stop the service at once and reiterate again to the step to fix the problem (stop the service, fix it, restore it).
Conclusion
These steps are obviously not usable all the time because of the variety of attacks you might encounter, but they can be used as a baseline to develop your own plan of actions. Again in such situations, keep your calm, don’t rush, and work to restore the system based on a clear set of steps.
If you had similar experiences please feel free to share your own tips to help others that might find themselves in such a situation.
Tuesday, July 18, 2006
What?! Rupert can't leave! He's the only one who know the SCLABE system!
Which is precisely why he's leaving. Poor Rupert has been trying to spend more time with the rest of the .NET team doing cool stuff, but he keeps getting dragged off to fix the old SCLABE* system.
Any time a tweak is required, Rupert's manager gets Rupert to do it, because he's been here the longest, knows it the most, and can fix it the quickest. And he knows exactly why an extra column is added on alternate weekends - a previous customer was having problems with their invoicing, so this was introduced to get round it.
But now Rupert's off, all his manager can think to do is get him to document what he knows about SCLABE. The thing is, Rupert's motivation percentage is equal to the number of days left at the company; today there are 17 days left, so he is 17% motivated. So Rupert adds a table of contents to the document, changes the headers and footers, tweaks "Heading 2" so it has 6pt spacing before and 12pt afterwards. He writes about the objectives of the system, describes the main areas of the system as an overview, and spends the rest of the day trying to get Visio to draw something resembling a diagram of the system.
In other words, he's wasting everyone's time.
To be fair, he's asked what he needs to write, and the answer was "enough for someone else to take over from you". Well, to take over, they need to know what the thing does, right? But that doesn't really help the next guy (who had better not be me) when the next tweak is required. There isn't any documentation that will help. There can't possibly be. Why? Because it isn't Rupert's knowledge that needs to be passed on, it's his experience. And that can't be passed on in a document. I can read a document telling me how to do a backside footplant wallride, but that doesn't mean I understand it, let alone have any success with it.
So what to do? For Rupert's boss, not a lot, except learn for next time. Rupert's experience needs to be passed on, which can only be achieved by showing someone. Although I've never been a manager, if I was stuck managing SCLABE, I would find a volunteer or two (willing or otherwise) to learn from Rupert. When a tweak is required, the volunteer, let's call her Ingrid, would sit at the keyboard, with Rupert next to her. Rupert would tell her how to navigate through the code, what to look for, how to implement the change, how to test it, where to deploy it to, and everything else, without actually doing it himself. Rupert would answer questions, and sometimes withhold information to make sure Ingrid thought about what she was doing. She would either work it out, or have to ask the right questions.
In this way, Ingrid would actually experience the system, and start to understand it. After a few of these sessions, she may be able to fix some things by herself. This would free up Rupert to get on with the cool AJAX stuff. If Rupert spent time with others in the team, then it would seem fair, and people could take turns. If Rupert left, then SCLABE fixes wouldn't be a major trauma, as someone else could do it. Rupert would be less likely to leave anyway, as he's now a confident, successful mentor, and even has time to write some Ruby on skis.
* SCLABE is a fictional legacy system written in COBOL on an AS/400. Rupert is a fictional developer, whose resemblance to anyone you know is the whole point of this exercise.
Any time a tweak is required, Rupert's manager gets Rupert to do it, because he's been here the longest, knows it the most, and can fix it the quickest. And he knows exactly why an extra column is added on alternate weekends - a previous customer was having problems with their invoicing, so this was introduced to get round it.
But now Rupert's off, all his manager can think to do is get him to document what he knows about SCLABE. The thing is, Rupert's motivation percentage is equal to the number of days left at the company; today there are 17 days left, so he is 17% motivated. So Rupert adds a table of contents to the document, changes the headers and footers, tweaks "Heading 2" so it has 6pt spacing before and 12pt afterwards. He writes about the objectives of the system, describes the main areas of the system as an overview, and spends the rest of the day trying to get Visio to draw something resembling a diagram of the system.
In other words, he's wasting everyone's time.
To be fair, he's asked what he needs to write, and the answer was "enough for someone else to take over from you". Well, to take over, they need to know what the thing does, right? But that doesn't really help the next guy (who had better not be me) when the next tweak is required. There isn't any documentation that will help. There can't possibly be. Why? Because it isn't Rupert's knowledge that needs to be passed on, it's his experience. And that can't be passed on in a document. I can read a document telling me how to do a backside footplant wallride, but that doesn't mean I understand it, let alone have any success with it.
So what to do? For Rupert's boss, not a lot, except learn for next time. Rupert's experience needs to be passed on, which can only be achieved by showing someone. Although I've never been a manager, if I was stuck managing SCLABE, I would find a volunteer or two (willing or otherwise) to learn from Rupert. When a tweak is required, the volunteer, let's call her Ingrid, would sit at the keyboard, with Rupert next to her. Rupert would tell her how to navigate through the code, what to look for, how to implement the change, how to test it, where to deploy it to, and everything else, without actually doing it himself. Rupert would answer questions, and sometimes withhold information to make sure Ingrid thought about what she was doing. She would either work it out, or have to ask the right questions.
In this way, Ingrid would actually experience the system, and start to understand it. After a few of these sessions, she may be able to fix some things by herself. This would free up Rupert to get on with the cool AJAX stuff. If Rupert spent time with others in the team, then it would seem fair, and people could take turns. If Rupert left, then SCLABE fixes wouldn't be a major trauma, as someone else could do it. Rupert would be less likely to leave anyway, as he's now a confident, successful mentor, and even has time to write some Ruby on skis.
* SCLABE is a fictional legacy system written in COBOL on an AS/400. Rupert is a fictional developer, whose resemblance to anyone you know is the whole point of this exercise.
Thursday, July 13, 2006
Confessions of an IT pro: My nine biggest professional blunders
July 12, 2006
Takeaway:
We've all had at least one or two embarrassing moments on the job, whether they involved inadvertently wreaking havoc on a system, making a social gaffe, or mishandling a project. IT pro Becky Roberts decided to come clean and share her worst career moments--along with the lessons she took away from each experience.
This article is also available as a PDF download.
Over the past 16 years of being paid to make computers and people work together in perfect harmony, I have collected a number of incidents that make me wince and blush in embarrassment when I think of them. The mistakes I've made fall roughly into three categories: technical, political, and career management. Here, in no particular order, are my most outstanding screw-ups and the lessons I have, I hope, learned.
#1: Accidentally deleting the VP's files without having a backup. I don't even remember how I did this. Not only did I delete the files, but it wasn't until the format was in process that I realized my mistake. I spent a nervous 30 minutes deciding how to deal with the situation. Should I lie and try to shift the blame? I couldn't blame any other person, as I was the whole IT department. Should I just return his computer and act dumb? "Well, the files were there when I gave the computer to you." Nothing I could think up felt right. In the end, I simply walked into his office, handed him his computer,and confessed, "I have screwed up. I deleted all your files and have no means of getting them back. It was completely my fault." Silence. Then: "Okay. Please be more careful in future." That was it. That was all he said. I could've kissed his feet, my feeling of relief matched only by the feeling of abject stupidity and incompetence.
Lesson learned? BACK UP BACK UP BACK-UP. Never delete, move, modify, upgrade, update, patch, flash, or format without making at least one backup. I have never knowingly lost a file since.
#2: Modifying the payroll program so no one received OT. This was at a ceramics factory in the Midwest. Payroll consisted of a Basic program on a minicomputer. A new rule for calculating overtime was to go into effect, and I was given the assignment of making the appropriate modification. I made the required change on a copy of the live program and did a walkthrough. The logic seemed flawless. I showed the program to my boss and he gave it his blessing. He said that he would put it into production at the start of the next pay period. Alarmed, I asked if we had a test system. I had been working for the company for just two months and was not familiar with the infrastructure. He grinned and said we didn't have one.
Two weeks later, a virtual riot broke out as the employees opened their checks to discover the awful truth: no overtime, none, nil, nothing, nada. My boss said I could go home early as I was looking horrifically pale.
Lesson learned? This is a tough one. Obviously, I had made a programming error and needed to improve my skills. But should I have realized that my abilities as a programmer weren't up to the task and tried to refuse the assignment? I did express my qualms about putting an untested program into production, but perhaps I should've done so more forcefully. Probably the most important lesson I learned from this incident is to ask very detailed questions about the infrastructure when interviewing for a new position and try to identify and avoid companies that don't support best practices.
#3: Going live on a demo copy of Exchange. I was a new hire into a two-person IT department and given the project of installing MS Exchange. The company was using a text-based freeware e-mail system, but it was so difficult to use there was no mail to migrate, so this could be a simple install.
I obtained a demo copy of Exchange, installed and configured it, and selected a small group of test users. I set up training for all users who were interested and soon expanded the "test" group to include all the employees. As days turned into weeks, the amount of data being stored grew rapidly. Users created folders and archives and entered their contacts. I ordered the appropriate Exchange licenses, assuming that they could be applied to the demo version. Finding no way to apply the license, I called Microsoft only to learn the heart-stopping truth that there was no way to apply the license, and worse, after 90 days the demo system would simply cease to function. This was day 88. Needless to say, I spent the next 48 hours on the phone with Microsoft tech support setting up a new server to replace the demo one, migrating data, and changing client configuration. It was one big, panicky mess. The only good to come out of this situation was that it turned into a great opportunity for learning.
Most salient of the many lessons learned?
* Don't go live on a demo application without first checking that it doesn't self-destruct on its expiration date.
* Make a project plan and stick to it. I should not have expanded the test group to the whole company.
* Improve communications with the users. They should not have been allowed to use the test system to the extent that they became dependent on it.
* Insist on being allowed to attend training before assuming responsibility for a new system.
#4: Taking backups for granted. Server backups were my sole responsibility. I set up the backup server and religiously changed tapes every day. The very first time a user needed a file restored, I discovered that the folder containing the file had not been successfully backed up for more than three months. Worse, the particular file in question had never been backed up. Suppressing the urge to blame the failure on a software fault rather than my own negligence, I went to the user and apologized. He was not at all impressed.
Lessons learned?
* Never take backups for granted.
* Check backup logs in detail daily.
* Practice restores on a routine basis.
* Set up a schedule for reviewing the backup strategy.
#5: Possessing unique knowledge. Although it may seem that possessing unique knowledge and skills within a company should offer some job security, not only is this a delusion but the possession of such knowledge can also become a burden that negatively affects your personal life. On several occasions throughout my career, I have allowed myself to be in just such a situation, where my failure to share my knowledge led to interrupted weekends with the family, phone calls at all hours of the night, phone calls while on vacation, and my favorite, a phone call to the ICU less than six hours after brain surgery.
Lesson learned? Document, share, and train. Sometimes, in a small company or during an implementation, it can be impossible not to possess unique knowledge. But staying aware and alert to the danger can minimize this risk. When provided with the appropriate documentation, it is surprising what even a relatively unskilled alternate can achieve in a crisis.
#6: Creating inadequate self-documentation. In addition to failing to document procedures for the purpose of sharing knowledge, I have shot myself in the foot on more than one occasion by failing to document a procedure or configuration I was sure I would remember. While working under pressure, with users breathing down my neck, it's all to easy to take shortcuts and make worthless self-promises to document later, when the crisis is over. Unfortunately, the next crisis hits, and then the next, and soon the documentation is forgotten until it's needed in the midst of yet another crisis.
Lesson learned? This lesson hasn't been fully learned yet. I've started taking screen shots and brief notes while working under pressure, but I still procrastinate in doing a full write-up after the crisis is over.
#7: Failing to establish the extent of my authority at the start of projects. Over the years, I have been the project manager for a variety of implementations, upgrades, and migrations. With one exception, each project was successful, in that the defined objectives were met by the deadline. But the process by which this was achieved was not necessarily the most efficient or the least stressful.
I hadn't seen the need to establish my authority at the start of a project as, until recently, all the members of each team had respected it. On a more recent project, in a very hierarchically structured company, my team consisted of a few peers, my boss, a couple of managers, and a VP. A more experienced PM suggested that I call a meeting specifically to determine exactly how much authority I had over the members of my team. I thought this was unnecessary and soon began to suffer as a result.
The project had various critical path items that had to be complete by specific dates, but despite my fervid attempts to communicate this to the team members responsible for the items, they would frequently thwart me: "I'm taking Friday off. My boss approved it." "I can't do that today; I need to do this." I had all the responsibility for the success of the project but none of the authority necessary to ensure its success. As a result, it was my first project not to meet the deadline.
Lessons learned? The first step of any project I am managing will be to establish what authority I am to be accorded. And if it's not sufficient to guarantee the success of the project, I'll have the temerity to either ask for more or suggest that a more senior project manager be appointed.
#8: Sending an insensitive e-mail to an employee. I received an e-mail from an employee detailing an extensive list of problems she was experiencing with her computer. Without any malicious intention, I shot off a reply saying that it sounded like new computer time. Thinking no more about it, I added her problems to my list of tasks for the day. A few minutes later, I was summoned into an emergency meeting with my supervisor and his boss. As I walked in the door, I was handed a printout of my e-mail reply to the employee and told to explain myself.
Thoroughly confused, I stated that I didn't understand what was going on. My boss explained that the employee was extremely offended by my e-mail as she had interpreted my levity as a refusal to take her problems seriously or help her. I was shocked that a few innocent words, an attempt at a lame joke, had been so drastically misunderstood. I was instructed to apologize to the user and fix her problems immediately.
Lessons learned?
* Do not attempt to be funny or clever in e-mail; play it completely straight.
* Have a formalized procedure for handling requests for help.
* Always inform users of when they can expect their problems to be addressed upon receipt of their request for help.
#9: Not taking advantage of free training and certification opportunities. Each time I have updated my resume in preparation for seeking a new job, I've regretted not having formal certifications to accompany my experience. This has been particularly irritating when the company I am trying to leave has a policy of paying for any classes the employees want to take, whether they're relevant to the business or not. It's kept me from applying to several jobs I was otherwise qualified for simply because they required possession of particular certifications.
Lessons learned? Take advantage of all free training opportunities, even if they have to be pursued out of business hours.
Takeaway:
We've all had at least one or two embarrassing moments on the job, whether they involved inadvertently wreaking havoc on a system, making a social gaffe, or mishandling a project. IT pro Becky Roberts decided to come clean and share her worst career moments--along with the lessons she took away from each experience.
This article is also available as a PDF download.
Over the past 16 years of being paid to make computers and people work together in perfect harmony, I have collected a number of incidents that make me wince and blush in embarrassment when I think of them. The mistakes I've made fall roughly into three categories: technical, political, and career management. Here, in no particular order, are my most outstanding screw-ups and the lessons I have, I hope, learned.
#1: Accidentally deleting the VP's files without having a backup. I don't even remember how I did this. Not only did I delete the files, but it wasn't until the format was in process that I realized my mistake. I spent a nervous 30 minutes deciding how to deal with the situation. Should I lie and try to shift the blame? I couldn't blame any other person, as I was the whole IT department. Should I just return his computer and act dumb? "Well, the files were there when I gave the computer to you." Nothing I could think up felt right. In the end, I simply walked into his office, handed him his computer,and confessed, "I have screwed up. I deleted all your files and have no means of getting them back. It was completely my fault." Silence. Then: "Okay. Please be more careful in future." That was it. That was all he said. I could've kissed his feet, my feeling of relief matched only by the feeling of abject stupidity and incompetence.
Lesson learned? BACK UP BACK UP BACK-UP. Never delete, move, modify, upgrade, update, patch, flash, or format without making at least one backup. I have never knowingly lost a file since.
#2: Modifying the payroll program so no one received OT. This was at a ceramics factory in the Midwest. Payroll consisted of a Basic program on a minicomputer. A new rule for calculating overtime was to go into effect, and I was given the assignment of making the appropriate modification. I made the required change on a copy of the live program and did a walkthrough. The logic seemed flawless. I showed the program to my boss and he gave it his blessing. He said that he would put it into production at the start of the next pay period. Alarmed, I asked if we had a test system. I had been working for the company for just two months and was not familiar with the infrastructure. He grinned and said we didn't have one.
Two weeks later, a virtual riot broke out as the employees opened their checks to discover the awful truth: no overtime, none, nil, nothing, nada. My boss said I could go home early as I was looking horrifically pale.
Lesson learned? This is a tough one. Obviously, I had made a programming error and needed to improve my skills. But should I have realized that my abilities as a programmer weren't up to the task and tried to refuse the assignment? I did express my qualms about putting an untested program into production, but perhaps I should've done so more forcefully. Probably the most important lesson I learned from this incident is to ask very detailed questions about the infrastructure when interviewing for a new position and try to identify and avoid companies that don't support best practices.
#3: Going live on a demo copy of Exchange. I was a new hire into a two-person IT department and given the project of installing MS Exchange. The company was using a text-based freeware e-mail system, but it was so difficult to use there was no mail to migrate, so this could be a simple install.
I obtained a demo copy of Exchange, installed and configured it, and selected a small group of test users. I set up training for all users who were interested and soon expanded the "test" group to include all the employees. As days turned into weeks, the amount of data being stored grew rapidly. Users created folders and archives and entered their contacts. I ordered the appropriate Exchange licenses, assuming that they could be applied to the demo version. Finding no way to apply the license, I called Microsoft only to learn the heart-stopping truth that there was no way to apply the license, and worse, after 90 days the demo system would simply cease to function. This was day 88. Needless to say, I spent the next 48 hours on the phone with Microsoft tech support setting up a new server to replace the demo one, migrating data, and changing client configuration. It was one big, panicky mess. The only good to come out of this situation was that it turned into a great opportunity for learning.
Most salient of the many lessons learned?
* Don't go live on a demo application without first checking that it doesn't self-destruct on its expiration date.
* Make a project plan and stick to it. I should not have expanded the test group to the whole company.
* Improve communications with the users. They should not have been allowed to use the test system to the extent that they became dependent on it.
* Insist on being allowed to attend training before assuming responsibility for a new system.
#4: Taking backups for granted. Server backups were my sole responsibility. I set up the backup server and religiously changed tapes every day. The very first time a user needed a file restored, I discovered that the folder containing the file had not been successfully backed up for more than three months. Worse, the particular file in question had never been backed up. Suppressing the urge to blame the failure on a software fault rather than my own negligence, I went to the user and apologized. He was not at all impressed.
Lessons learned?
* Never take backups for granted.
* Check backup logs in detail daily.
* Practice restores on a routine basis.
* Set up a schedule for reviewing the backup strategy.
#5: Possessing unique knowledge. Although it may seem that possessing unique knowledge and skills within a company should offer some job security, not only is this a delusion but the possession of such knowledge can also become a burden that negatively affects your personal life. On several occasions throughout my career, I have allowed myself to be in just such a situation, where my failure to share my knowledge led to interrupted weekends with the family, phone calls at all hours of the night, phone calls while on vacation, and my favorite, a phone call to the ICU less than six hours after brain surgery.
Lesson learned? Document, share, and train. Sometimes, in a small company or during an implementation, it can be impossible not to possess unique knowledge. But staying aware and alert to the danger can minimize this risk. When provided with the appropriate documentation, it is surprising what even a relatively unskilled alternate can achieve in a crisis.
#6: Creating inadequate self-documentation. In addition to failing to document procedures for the purpose of sharing knowledge, I have shot myself in the foot on more than one occasion by failing to document a procedure or configuration I was sure I would remember. While working under pressure, with users breathing down my neck, it's all to easy to take shortcuts and make worthless self-promises to document later, when the crisis is over. Unfortunately, the next crisis hits, and then the next, and soon the documentation is forgotten until it's needed in the midst of yet another crisis.
Lesson learned? This lesson hasn't been fully learned yet. I've started taking screen shots and brief notes while working under pressure, but I still procrastinate in doing a full write-up after the crisis is over.
#7: Failing to establish the extent of my authority at the start of projects. Over the years, I have been the project manager for a variety of implementations, upgrades, and migrations. With one exception, each project was successful, in that the defined objectives were met by the deadline. But the process by which this was achieved was not necessarily the most efficient or the least stressful.
I hadn't seen the need to establish my authority at the start of a project as, until recently, all the members of each team had respected it. On a more recent project, in a very hierarchically structured company, my team consisted of a few peers, my boss, a couple of managers, and a VP. A more experienced PM suggested that I call a meeting specifically to determine exactly how much authority I had over the members of my team. I thought this was unnecessary and soon began to suffer as a result.
The project had various critical path items that had to be complete by specific dates, but despite my fervid attempts to communicate this to the team members responsible for the items, they would frequently thwart me: "I'm taking Friday off. My boss approved it." "I can't do that today; I need to do this." I had all the responsibility for the success of the project but none of the authority necessary to ensure its success. As a result, it was my first project not to meet the deadline.
Lessons learned? The first step of any project I am managing will be to establish what authority I am to be accorded. And if it's not sufficient to guarantee the success of the project, I'll have the temerity to either ask for more or suggest that a more senior project manager be appointed.
#8: Sending an insensitive e-mail to an employee. I received an e-mail from an employee detailing an extensive list of problems she was experiencing with her computer. Without any malicious intention, I shot off a reply saying that it sounded like new computer time. Thinking no more about it, I added her problems to my list of tasks for the day. A few minutes later, I was summoned into an emergency meeting with my supervisor and his boss. As I walked in the door, I was handed a printout of my e-mail reply to the employee and told to explain myself.
Thoroughly confused, I stated that I didn't understand what was going on. My boss explained that the employee was extremely offended by my e-mail as she had interpreted my levity as a refusal to take her problems seriously or help her. I was shocked that a few innocent words, an attempt at a lame joke, had been so drastically misunderstood. I was instructed to apologize to the user and fix her problems immediately.
Lessons learned?
* Do not attempt to be funny or clever in e-mail; play it completely straight.
* Have a formalized procedure for handling requests for help.
* Always inform users of when they can expect their problems to be addressed upon receipt of their request for help.
#9: Not taking advantage of free training and certification opportunities. Each time I have updated my resume in preparation for seeking a new job, I've regretted not having formal certifications to accompany my experience. This has been particularly irritating when the company I am trying to leave has a policy of paying for any classes the employees want to take, whether they're relevant to the business or not. It's kept me from applying to several jobs I was otherwise qualified for simply because they required possession of particular certifications.
Lessons learned? Take advantage of all free training opportunities, even if they have to be pursued out of business hours.
Wednesday, July 12, 2006
Help With The College To Career Transition
Interesting article for graduating students in search of jobs.. and a career..
Changing from a career as a college student to the dreaded career in “the real world” leaves many students in somewhat of a culture shock. Many college students have an internship or two under their belt by the time they get to college and I highly recommend that to ease the transition.
Here are some things that you can realize or change as a college student that will help you in moving to a 9 to 5:
1. Change doesn’t come easy
Most college students come out thinking they will fix everything in a company. Keep this attitude but be realistic. Even if the way something is done now is inefficient, change is a big deal. People don’t like to change because they have to re-learn or break a habit. There is also usually a bigger picture than you don’t yet know. Just because it should change doesn’t mean it will.
2. Connections often trump performance
You will experience this especially in your job search. The easiest way to get a job is not submitting your resume online, but through someone on the inside. You are also going to see this in your superiors and co-workers. Your superior may not be as qualified or knowledgeable, but they know more people than you. Of course connections without good performance backing you up will catch up to you.
3. Be a nerd, but with social skills
Nerds are not hugely succesful, nerds with social skills are successful. Unless you invent time travel, how well you can talk to a computer doesn’t matter if you can’t also talk to superiors, co-workers, investors and customers.
4. Keep it simple
Many students try to impress with essay emails or big words. Emails should reflect the way you would explain in person. Long emails get ignored or skimmed, so keep them short and/or bulleted. Don’t make me get a dictionary or read a novel.
5. Be casual, yet professional
You will not talk work all the time. Share stories to build relationships, but learn what to talk about with different people. You won’t share the same stories or detail with superiors as you do peers. Even with peers it is possible to go to far.
6. Use your first job experience
More than likely your first job is not where you will retire. You need that job to get experience, but it doesn’t have to be your life’s calling. Use what you learn to find out what it is you do want to do for the rest of your life.
7. Maintain an attitude of innovation
While this may seem to contradict some of what I said, maintain an attitude of bringing innovation. The routine of working can dull your creativity, but people don’t get promoted (usually) for consistently meeting expectations. Bringing innovation will exceed expectations, so maintain your “change the world” attitude, but don’t expect it to happen tomorrow.
Changing from a career as a college student to the dreaded career in “the real world” leaves many students in somewhat of a culture shock. Many college students have an internship or two under their belt by the time they get to college and I highly recommend that to ease the transition.
Here are some things that you can realize or change as a college student that will help you in moving to a 9 to 5:
1. Change doesn’t come easy
Most college students come out thinking they will fix everything in a company. Keep this attitude but be realistic. Even if the way something is done now is inefficient, change is a big deal. People don’t like to change because they have to re-learn or break a habit. There is also usually a bigger picture than you don’t yet know. Just because it should change doesn’t mean it will.
2. Connections often trump performance
You will experience this especially in your job search. The easiest way to get a job is not submitting your resume online, but through someone on the inside. You are also going to see this in your superiors and co-workers. Your superior may not be as qualified or knowledgeable, but they know more people than you. Of course connections without good performance backing you up will catch up to you.
3. Be a nerd, but with social skills
Nerds are not hugely succesful, nerds with social skills are successful. Unless you invent time travel, how well you can talk to a computer doesn’t matter if you can’t also talk to superiors, co-workers, investors and customers.
4. Keep it simple
Many students try to impress with essay emails or big words. Emails should reflect the way you would explain in person. Long emails get ignored or skimmed, so keep them short and/or bulleted. Don’t make me get a dictionary or read a novel.
5. Be casual, yet professional
You will not talk work all the time. Share stories to build relationships, but learn what to talk about with different people. You won’t share the same stories or detail with superiors as you do peers. Even with peers it is possible to go to far.
6. Use your first job experience
More than likely your first job is not where you will retire. You need that job to get experience, but it doesn’t have to be your life’s calling. Use what you learn to find out what it is you do want to do for the rest of your life.
7. Maintain an attitude of innovation
While this may seem to contradict some of what I said, maintain an attitude of bringing innovation. The routine of working can dull your creativity, but people don’t get promoted (usually) for consistently meeting expectations. Bringing innovation will exceed expectations, so maintain your “change the world” attitude, but don’t expect it to happen tomorrow.
Monday, July 10, 2006
find .. linux
CLI Magic: Searching with find
The find command is one of the darkest and least understood areas of Linux, but it is also one of the most powerful. The biggest problem with find is that it has more options than most people can remember -- it truly is capable of doing most things you could want.
Admittedly, the find command does not help itself by using X-style parameters. The Unix standard is -c, -s, and so on, whereas the GNU standard is --dosomething, --mooby, and so forth. X-style parameters merge the two by having words preceded by only one dash. The most basic usage is this:
find -name "*.txt"
That query searches the current directory and all subdirectories for files that end in .txt. The previous search finds files ending in .txt but not .TXT, .Txt, or other case variations. To search without case sensitivity, use -iname instead of -name. You can optionally specify where the search should start before the -name parameter, like this:
find /home -name "*.txt"
Another useful test is -size, which lets you specify how big the files should be to match. You can specify your size in kilobytes and optionally also use + or - to specify greater than or less than. For example:
find /home -name "*.txt" -size 100k find /home -name "*.txt" -size +100k find /home -name "*.txt" -size -100k The first brings up files of exactly 100KB, the second only files greater than 100KB, and the last only files less than 100KB.
The -user option enables you to specify the user that owns the files you are looking for. So, to search for all files in /home that end with .txt, are under 100KB, and are owned by user paul, you would use this:
find /home -name "*.txt" -size -100k -user paul
You can flip any of the conditions by specifying -not before them. For example, you can add a -not before -user paul to find matching files owned by everyone but paul:
find /home -name "*.txt" -size -100k -not -user paul
You can add as many -not parameters as you need, even using -not -not to cancel each other out! (Yes, that is pointless.) Keep in mind, though, that -not -size -100k is essentially equivalent to -size +100k, with the exception that the former will match files of exactly 100KB whereas the latter will not.
You can use -perm to specify which permissions a file should have for it to be matched. This is tricky, so read carefully. The permissions are specified in the same way as with the chmod command: u for user, g for group, o for others, r for read, w for write, and x for execute. However, before you give the permissions, you need to specify a plus, a minus, or a blank space. If you specify neither a plus nor a minus, the files must exactly match the mode you give. If you specify -, the files must match all the modes you specify. If you specify +, the files must match any the modes you specify. Confused yet?
The confusion can be cleared up with some examples. This next command finds all files that have permission o=r (readable for other users). Notice that if you remove the -name parameter, it is equivalent to * because all filenames are matched.
find /home -perm -o=r
Any files that have o=r set are returned from that query. Those files also might have u=rw and other permissions, but as long as they have o=r, they will match. This next query matches all files that have o=rw set:
find /home -perm -o=rw
However, that query does not match files that are o=r or o=w. To be matched, a file must be readable and writeable by other users. If you want to match readable or writeable (or both), you need to use +, like this:
find /home -perm +o=rw
Similarly, this next query matches files that are only readable by user, group, and others:
find /home -perm -ugo=r
Whereas this query matches files as long as they are readable by the user, or by the group, or by others, or by any combination of the three:
find /home -perm +ugo=r
If you use neither + nor -, you are specifying the exact permissions to search for. For example, the next query searches for files that are readable by user, group, and others but not writeable or executable by anyone:
find /home -perm ugo=r
You can be as specific as you need to be with the permissions. For example, this query finds all files that are readable for the user, group, and others and writeable by the user:
find /home -perm ugo=r,u=w
To find files that are not readable by others, use the -not condition, like this:
find /home -not -perm +o=r
Now, on to the most advanced aspect of the find command: the -exec parameter. This enables you to execute an external program each time a match is made, passing in the name of the matched file wherever you want it. This has very specific syntax: Your command and its parameters should follow immediately after -exec, terminated by \;. You can insert the filename match at any point using {} (an opening and a closing brace side by side).
So, you can match all text files on the entire system (that is, searching recursively from / rather than from /home as in our previous examples) over 10KB, owned by paul, that are not readable by other users, and then use chmod to enable reading, like this:
find / -name "*.txt" -size +10k -user paul -not -perm +o=r -exec chmod o+r {} \;
When you type your own -exec parameters, be sure to include a space before \;. Otherwise, you might see an error such as missing argument to ´-exec'.
Do you see now why some people think the find command is scary? Many people learn just enough about find to be able to use it in a very basic way, but hopefully you will see how much it can do if you give it a chance.
Wednesday, July 05, 2006
11 "Don't-Tell-the-Wife" Secrets All Men Keep --- By Ty Wenger
I was in the ninth grade when I learned a vital lesson about love. My girlfriend at the time, Amy, was stunningly cute, frighteningly smart and armed with a seemingly endless supply of form-fitting angora sweaters. And me? Let's just say I was an adolescent Chris Robinson to her budding Kate Hudson -- and well aware of my good fortune.
More from Redbook
* "He cheated. Now what?"
* Guy Behavior 101
* "The best marriage advice I ever got."
* 12 Things Men Really Find Romantic
* Sex Secrets of Really Happy Couples
Then one day, as we stood in line for a movie at the mall, Simone Shaw, junior high prom queen, sauntered by. Suddenly Amy turned to me. "Were you looking at her?" she asked. "Do you think she's pretty?"
My mind reeled. Of course I was looking at her! Of course she was pretty! My God, she was Simone Shaw! I paused for a second, then decided to play it straight.
"Well, yeah," I chortled.
Five days later our breakup hit the tabloids (a.k.a. the lunchroom).
There comes a time in every man's life when he discovers the value of hiding the grosser parts of his nature. He starts reciting the sweet nothings you long to hear: "No, honey, I play golf for the exercise." "No, honey, I think you're a great driver." "No, honey, I wasn't looking at that coed washing the car in the rain."
We're not lying, exactly. We're just making things...easier. But Glenn Good, Ph.D., a relationship counselor, disagrees, and maybe he has a point. "These white lies are pretty innocent, but they can turn confusing," he says. "Many women think, If he's lying about himself, is he also lying about something else? Is he having an affair? To establish trust you have to tell the truth about the innocuous stuff."
And so, in the interest of uniting the sexes, we've scoured the country for guys willing to share the private truths they wouldn't normally confess. Some are a bit crass. Some you've always suspected. Some are surprisingly sweet. (Guys don't like to reveal the mushy stuff, either.) But read on, and you may discover that the truth about men isn't all that ugly.
Secret #1: Yes, we fall in lust 10 times a day -- but it doesn't mean we want to leave you
If the oldest question in history is "What's for dinner?" the second oldest is "Were you looking at her?" The answer: Yes -- yes, we were. If you're sure your man doesn't look, it only means he possesses acute peripheral vision.
"When a woman walks by, even if I'm with my girlfriend, my vision picks it up," says Doug LaFlamme, 28, of Laguna Hills, California. "I fight the urge to look, but I just have to. I'm really in trouble if the woman walking by has a low-cut top on."
Granted, we men are well aware that our sizing up the produce doesn't sit well with you, given that we've already gone through the checkout line together. But our passing glances pose no threat.
"It's not that I want to make a move on her," says LaFlamme. "Looking at other women is like a radar that just won't turn off."
Secret #2: We actually do play golf to get away from you
More than 21 million American men play at least one round of golf a year; of those, an astounding 75 percent regularly shoot worse than 90 strokes a round. In other words, they stink. The point is this: "Going golfing" is not really about golf. It's about you, the house, the kids -- and the absence thereof.
"I certainly don't play because I find it relaxing and enjoyable," admits Roland Buckingham, 32, of Lewes, Delaware, whose usual golf score of 105 is a far-from-soothing figure. "As a matter of fact, sometimes by the fourth hole I wish I were back at the house with the kids screaming. But any time I leave the house and don't invite my wife or kids -- whether it's for golf or bowling or picking up roadkill -- I'm just getting away."
Secret #3: We're unnerved by the notion of commitment, even after we've made one to you
This is a dicey one, so first things first: We love you to death. We think you're fantastic. Most of the time we're absolutely thrilled that we've made a lifelong vow of fidelity to you in front of our families, our friends and an expensive videographer.
But most of us didn't spend our formative years thinking, "Gosh, I just can't wait to settle down with a nice girl so we can grow old together." Instead we were obsessed with how many women who resembled Britney Spears we could have sex with before we turned 30. Generally it takes us a few years (or decades) to fully perish that thought.
Secret #4: Earning money makes us feel important
In more than 7.4 million U.S. marriages, the wife earns more than the husband -- almost double the number in 1981. This of course is a terrific development for women in the workplace and warmly embraced by all American men, right? Right?
Yeah, well, that's what we tell you. But we're shallow, competitive egomaniacs. You don't think it gets under our skin if our woman's bringing home more bacon than we are -- and frying it up in a pan?
"My wife and I are both reporters at the same newspaper," says Jeffrey Newton, 33, of Fayetteville, South Carolina. "Five years into our marriage I still check her pay stub to see how much more an hour I make than she does. And because she works harder, she keeps closing the gap."
Secret #5: Though we often protest, we actually enjoy fixing things around the house
I risk being shunned at the local bar if this magazine finds its way there, because few charades are as beloved by guys as this one. To hear us talk, the Bataan Death March beats grouting that bathroom shower. And, as 30-year-old Ed Powers of Chicago admits, it's a shameless lie. "In truth, it's rewarding to tinker with and fix something that, without us, would remain broken forever," he says. Plus we get to use tools.
"The reason we don't share this information," Powers adds, "is that most women don't differentiate between taking out the trash and fixing that broken hinge; to them, both are tasks we need to get done over the weekend, preferably during the Bears game. But we want the use-your-hands, think-about-the-steps-in-the-process, home-repair opportunity, not the repetitive, no-possibility-of-a-compliment, mind-dulling, purely physical task." There. Secret's out.
Secret #6: We like it when you mother us, but we're terrified that you'll become your mother
With apologies to Sigmund Freud, Gloria Steinem -- and my mother-in-law.
Secret #7: Every year we love you more
Sure, we look like adults. We own a few suits. We can probably order wine without giggling. But although we resemble our father when he was our age, we still feel like that 4-year-old clutching his pant leg.
With that much room left on our emotional-growth charts, we sense we've only begun to admire you in the ways we will when we're 40, 50 and -- God forbid -- 60. We can't explain this to you, because it would probably come out sounding like we don't love you now.
"It took at least a year before I really started to appreciate my wife for something other than just great sex; and I didn't discover her mind fully until the third year we were married," says Newton. "But the older and wiser I get, the more I love my wife." Adds J.P. Neal, 32, of Potomac, Maryland: "The for-richer-or-poorer, for-better-or-worse aspects of marriage don't hit you right away. It's only during those rare times when we take stock of our life that it starts to sink in."
Secret #8: We don't really understand what you're talking about
You know how, during the day, you sometimes think about certain deep, complex "issues" in your relationship? Then when you get home, you want to "discuss" these issues? And during these "discussions," your man sits there nodding and saying things like "Sure, I understand," "That makes perfect sense" and "I'll do better next time"?
Well, we don't understand. It doesn't make any sense to us at all. And although we'd like to do better next time, we could only do so if, in fact, we had an idea of what you're talking about.
We do care. Just be aware that the part of our brain that processes this stuff is where we store sports trivia.
Secret #9: We are terrified when you drive
Want to know how to reduce your big, tough guy to a quivering mass of fear? Ask him for the car keys.
"I am scared to death when she drives," says LaFlamme.
"Every time I ride with her, I fully accept that I may die at any moment," says Buckingham.
"My wife has about one 'car panic' story a week -- and it's never her fault. All these horrible things just keep happening -- it must be her bad luck," says Andy Beshuk, 31, of Jefferson City, Missouri.
Even if your man is too diplomatic to tell you, he is terrified that you will turn him into a crash-test dummy.
Secret #10: We'll always wish we were 25 again
Granted, when I was 25 I was working 16-hour days and eating shrimp-flavored Ramen noodles six times a week. But as much as we love being with you now, we will always look back fondly on the malnourished freedom of our misguided youth. "Springsteen concerts, the '91 Mets, the Clinton presidency -- most guys reminisce about the days when life was good, easy and free of responsibility," says Rob Aronson, 41, of Livingston, New Jersey, who's been married for 11 years. "At 25 you can get away with things you just can't get away with at 40."
While it doesn't mean we're leaving you to join a rock band, it does explain why we occasionally come home from Pep Boys with a leather steering-wheel cover and a Born to Run CD.
Secret #11: Give us an inch and we'll give you a lifetime
I was on a trip to Mexico, standing on a beach, waxing my surfboard and admiring the glistening 10-foot waves, when I decided to marry the woman who is now my wife. Sure, this was three years before I got around to popping the question. But that was when I knew.
Why? Because she'd let me go on vacation alone. Hell, she made me go. This is the most important thing a man never told you: If you let us be dumb guys, if you embrace our stupid poker night, if you encourage us to go surfing -- by ourselves -- our silly little hearts, with their manly warts and all, will embrace you forever for it.
And that's the truth.
More from Redbook
* "He cheated. Now what?"
* Guy Behavior 101
* "The best marriage advice I ever got."
* 12 Things Men Really Find Romantic
* Sex Secrets of Really Happy Couples
Then one day, as we stood in line for a movie at the mall, Simone Shaw, junior high prom queen, sauntered by. Suddenly Amy turned to me. "Were you looking at her?" she asked. "Do you think she's pretty?"
My mind reeled. Of course I was looking at her! Of course she was pretty! My God, she was Simone Shaw! I paused for a second, then decided to play it straight.
"Well, yeah," I chortled.
Five days later our breakup hit the tabloids (a.k.a. the lunchroom).
There comes a time in every man's life when he discovers the value of hiding the grosser parts of his nature. He starts reciting the sweet nothings you long to hear: "No, honey, I play golf for the exercise." "No, honey, I think you're a great driver." "No, honey, I wasn't looking at that coed washing the car in the rain."
We're not lying, exactly. We're just making things...easier. But Glenn Good, Ph.D., a relationship counselor, disagrees, and maybe he has a point. "These white lies are pretty innocent, but they can turn confusing," he says. "Many women think, If he's lying about himself, is he also lying about something else? Is he having an affair? To establish trust you have to tell the truth about the innocuous stuff."
And so, in the interest of uniting the sexes, we've scoured the country for guys willing to share the private truths they wouldn't normally confess. Some are a bit crass. Some you've always suspected. Some are surprisingly sweet. (Guys don't like to reveal the mushy stuff, either.) But read on, and you may discover that the truth about men isn't all that ugly.
Secret #1: Yes, we fall in lust 10 times a day -- but it doesn't mean we want to leave you
If the oldest question in history is "What's for dinner?" the second oldest is "Were you looking at her?" The answer: Yes -- yes, we were. If you're sure your man doesn't look, it only means he possesses acute peripheral vision.
"When a woman walks by, even if I'm with my girlfriend, my vision picks it up," says Doug LaFlamme, 28, of Laguna Hills, California. "I fight the urge to look, but I just have to. I'm really in trouble if the woman walking by has a low-cut top on."
Granted, we men are well aware that our sizing up the produce doesn't sit well with you, given that we've already gone through the checkout line together. But our passing glances pose no threat.
"It's not that I want to make a move on her," says LaFlamme. "Looking at other women is like a radar that just won't turn off."
Secret #2: We actually do play golf to get away from you
More than 21 million American men play at least one round of golf a year; of those, an astounding 75 percent regularly shoot worse than 90 strokes a round. In other words, they stink. The point is this: "Going golfing" is not really about golf. It's about you, the house, the kids -- and the absence thereof.
"I certainly don't play because I find it relaxing and enjoyable," admits Roland Buckingham, 32, of Lewes, Delaware, whose usual golf score of 105 is a far-from-soothing figure. "As a matter of fact, sometimes by the fourth hole I wish I were back at the house with the kids screaming. But any time I leave the house and don't invite my wife or kids -- whether it's for golf or bowling or picking up roadkill -- I'm just getting away."
Secret #3: We're unnerved by the notion of commitment, even after we've made one to you
This is a dicey one, so first things first: We love you to death. We think you're fantastic. Most of the time we're absolutely thrilled that we've made a lifelong vow of fidelity to you in front of our families, our friends and an expensive videographer.
But most of us didn't spend our formative years thinking, "Gosh, I just can't wait to settle down with a nice girl so we can grow old together." Instead we were obsessed with how many women who resembled Britney Spears we could have sex with before we turned 30. Generally it takes us a few years (or decades) to fully perish that thought.
Secret #4: Earning money makes us feel important
In more than 7.4 million U.S. marriages, the wife earns more than the husband -- almost double the number in 1981. This of course is a terrific development for women in the workplace and warmly embraced by all American men, right? Right?
Yeah, well, that's what we tell you. But we're shallow, competitive egomaniacs. You don't think it gets under our skin if our woman's bringing home more bacon than we are -- and frying it up in a pan?
"My wife and I are both reporters at the same newspaper," says Jeffrey Newton, 33, of Fayetteville, South Carolina. "Five years into our marriage I still check her pay stub to see how much more an hour I make than she does. And because she works harder, she keeps closing the gap."
Secret #5: Though we often protest, we actually enjoy fixing things around the house
I risk being shunned at the local bar if this magazine finds its way there, because few charades are as beloved by guys as this one. To hear us talk, the Bataan Death March beats grouting that bathroom shower. And, as 30-year-old Ed Powers of Chicago admits, it's a shameless lie. "In truth, it's rewarding to tinker with and fix something that, without us, would remain broken forever," he says. Plus we get to use tools.
"The reason we don't share this information," Powers adds, "is that most women don't differentiate between taking out the trash and fixing that broken hinge; to them, both are tasks we need to get done over the weekend, preferably during the Bears game. But we want the use-your-hands, think-about-the-steps-in-the-process, home-repair opportunity, not the repetitive, no-possibility-of-a-compliment, mind-dulling, purely physical task." There. Secret's out.
Secret #6: We like it when you mother us, but we're terrified that you'll become your mother
With apologies to Sigmund Freud, Gloria Steinem -- and my mother-in-law.
Secret #7: Every year we love you more
Sure, we look like adults. We own a few suits. We can probably order wine without giggling. But although we resemble our father when he was our age, we still feel like that 4-year-old clutching his pant leg.
With that much room left on our emotional-growth charts, we sense we've only begun to admire you in the ways we will when we're 40, 50 and -- God forbid -- 60. We can't explain this to you, because it would probably come out sounding like we don't love you now.
"It took at least a year before I really started to appreciate my wife for something other than just great sex; and I didn't discover her mind fully until the third year we were married," says Newton. "But the older and wiser I get, the more I love my wife." Adds J.P. Neal, 32, of Potomac, Maryland: "The for-richer-or-poorer, for-better-or-worse aspects of marriage don't hit you right away. It's only during those rare times when we take stock of our life that it starts to sink in."
Secret #8: We don't really understand what you're talking about
You know how, during the day, you sometimes think about certain deep, complex "issues" in your relationship? Then when you get home, you want to "discuss" these issues? And during these "discussions," your man sits there nodding and saying things like "Sure, I understand," "That makes perfect sense" and "I'll do better next time"?
Well, we don't understand. It doesn't make any sense to us at all. And although we'd like to do better next time, we could only do so if, in fact, we had an idea of what you're talking about.
We do care. Just be aware that the part of our brain that processes this stuff is where we store sports trivia.
Secret #9: We are terrified when you drive
Want to know how to reduce your big, tough guy to a quivering mass of fear? Ask him for the car keys.
"I am scared to death when she drives," says LaFlamme.
"Every time I ride with her, I fully accept that I may die at any moment," says Buckingham.
"My wife has about one 'car panic' story a week -- and it's never her fault. All these horrible things just keep happening -- it must be her bad luck," says Andy Beshuk, 31, of Jefferson City, Missouri.
Even if your man is too diplomatic to tell you, he is terrified that you will turn him into a crash-test dummy.
Secret #10: We'll always wish we were 25 again
Granted, when I was 25 I was working 16-hour days and eating shrimp-flavored Ramen noodles six times a week. But as much as we love being with you now, we will always look back fondly on the malnourished freedom of our misguided youth. "Springsteen concerts, the '91 Mets, the Clinton presidency -- most guys reminisce about the days when life was good, easy and free of responsibility," says Rob Aronson, 41, of Livingston, New Jersey, who's been married for 11 years. "At 25 you can get away with things you just can't get away with at 40."
While it doesn't mean we're leaving you to join a rock band, it does explain why we occasionally come home from Pep Boys with a leather steering-wheel cover and a Born to Run CD.
Secret #11: Give us an inch and we'll give you a lifetime
I was on a trip to Mexico, standing on a beach, waxing my surfboard and admiring the glistening 10-foot waves, when I decided to marry the woman who is now my wife. Sure, this was three years before I got around to popping the question. But that was when I knew.
Why? Because she'd let me go on vacation alone. Hell, she made me go. This is the most important thing a man never told you: If you let us be dumb guys, if you embrace our stupid poker night, if you encourage us to go surfing -- by ourselves -- our silly little hearts, with their manly warts and all, will embrace you forever for it.
And that's the truth.
Subscribe to:
Comments (Atom)