I like the concept of “hats.” I took an IBM class on Transformational Leadership that was intended to broaden one’s thinking and make you a more creative and efficient employee. In this class the team of instructors would make big use of hats to portray roles. Later I was an instructor in the IBM Global Services Institute and we wore hats to indicate the roles we were playing. I had a great beanie with a propellor on top that I wore to signify the role of technical person I would play while giving support for IBM Smalltalk, an object oriented programming language the students used to complete assignments in the class.
So I thought I would go over some of the roles or “hats” I wore during my 33 year career with IBM. I started out as a final test technician. That means I was responsible for verifying that the Series III Copier was in perfect operating condition before we shipped it. This was no small task. There were over 60 of us in final test and we spent around six hours per machine setting up and adjusting the final product and verifying that it would perform all required functions to specifications.
I had worked in precision measurement and electronic equipment calibration in the Navy and had experience with final test from my time at A.R.F. Products. Testing has been a common thread throughout most of my career. I often worked as a tester or taught testing or managed testing from the beginning to the end of my time at IBM.
So, with the help of Google and a lot of web sites, permit me to present my view of the various roles I’ve played. Bear with me as I use this as a weak excuse to tell every joke I’ve ever heard about engineers, programmers, project managers, and other various and assundary workplace roles.
I was once told that a Project Manager is a person who thinks that nine women can deliver a baby in one month. The Client is the one who doesn’t know why he wants a baby, and the Tester is a person who always says that this is not the right baby.
Now we know that testing is the process of gathering information by making observations and comparing them to expectations and a test is an experiment designed to reveal information or answer a specific question about the software or system.
My definition is that testers are people good at breaking things. We all know about the child that plays in the box the toy came in, rather than the toy. Well, you can recognize a young tester by the fact that they break all the toys. To them, an unbreakable toy is just something useful for breaking other toys.
Somewhere in my career I became a software engineer. That is, a software developer or programmer. A programmer is someone who solves a problem you didn’t know you had in a way you don’t understand. If architects built buildings the way programmers build programs, then the first woodpecker that came along would destroy civilization.
I also worked as a consultant which is someone who takes the watch off your wrist and tells you the time. Still that’s better than a banker who is a fellow who lends you his umbrella when the sun is shining and wants it back the minute it begins to rain (Mark Twain). Or an economist who is an expert who will know tomorrow why the things he predicted yesterday didn’t happen today.
Programmer is a person who passes as an exacting expert on the basis of being able to turn out, after innumberable poundings, an infinite series of incomprehensive answers calculated with micrometric precisions from vague assumptions based on debatable figures from inconclusive documents and carried out on instruments of problematical accuracy by persons of dubious reliability and questionable mentality for the avowed purpose of annoying and confounding a hopelessly defenseless department that was unfortunate enough to ask for the information in the first place. Or is that an engineer?
I also worked as a Project Manager. I was IBM Certified and a member of the Project Manager’s Institute. These were qualifications I received by lying about my training and experience to a bunch of other managers who had lied about their experience and training to get the job of certifying project managers.
A tourist walked into a pet shop and was looking at the animals on display. While he was there, another customer walked in and said to the shopkeeper, "I'll have a C monkey please." The shopkeeper nodded, went over to a cage at the side of the shop, and took out a monkey. He fitted a collar and leash, handed to the customer, saying, "That'll be $5,000."
The customer paid and walked out with his monkey. Startled, the tourist went over to the shopkeeper and said, "That was a very expensive monkey. Most of them are only a few hundred dollars. Why did it cost so much?" The shopkeeper answered, "Ah, that monkey can program in C — very fast, tight code, no bugs, well worth the money."
The tourist looked at a monkey in another cage. "Hey, that one's even more expensive! $10,000! What does it do?"
"Oh,that one's a C++ monkey; it can manage object-oriented programming, Visual C++, even some Java. All the really useful stuff," said the shopkeeper.
The tourist looked around for a little longer and saw a third monkey in a cage of its own. The price tag around its neck read $50,000. The tourist gasped to the shopkeeper, "That one costs more than all the others put together! What on earth does it do?"
The shopkeeper replied, "Well, I haven't actually seen it do anything, but it says it's a project manager."
It is quite simple to be a project manager. You have to be responsible. When anything goes wrong, you are responsible. Just follow these simple rules and you will be certifiable before long.
1. Nothing is impossible for the person who doesn't have to do it.
2. You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.
3. At the heart of every large project is a small project trying to get out.
4. The more desperate the situation the more optimistic the situatee.
5. A problem shared is a buck passed.
6. A change freeze is like the abominable snowman: it is a myth and would melt anyway when heat is applied.
7. A user will tell you anything you ask, but nothing more.
8. Of several possible interpretations of a communication, the least convenient is the correct one.
9. What you don't know hurts you
10. There's never enough time to do it right first time but there's always enough time to go back and do it again.
11. The bitterness of poor quality lasts long after the sweetness of making a date is forgotten.
12. I know that you believe that you understand what you think I said, but I am not sure you realise that what you heard is not what I meant.
13. What is not on paper has not been said.
14. A little risk management saves a lot of fan cleaning.
15. If you can keep your head while all about you are losing theirs, you haven't understood the plan.
16. If at first you don't succeed, remove all evidence you ever tried.
17. Feather and down are padding, changes and contingencies will be real events.
18. There are no good project managers — only lucky ones.
19. The more you plan the luckier you get.
20. A project is one small step for the project sponsor, one giant leap for the project manager.
21. Good project management is not so much knowing what to do and when, as knowing what excuses to give and when.
22. If everything is going exactly to plan, something somewhere is going massively wrong.
23. Everyone asks for a strong project manger — when they get one, they don't want one.
24. Overtime is a figment of the naïve project manager's imagination.
25. Quantitative project management is for predicting cost and schedule overruns well in advance.
26. The sooner you begin coding the later you finish.
27. Metrics are learned men's excuses.
28. For a project manager, overruns are as certain as death and taxes.
29. Some projects finish on time in spite of project management best practices.
30. Fast — cheap — good — you can have any two.
31. There is such a thing as an unrealistic timescale.
32. The project would not have been started if the truth had been told about the cost and timescale.
33. A two-year project will take three years; a three-year project will never finish.
34. When the weight of the project paperwork equals the weight of the project itself, the project can be considered complete.
35. A badly planned project will take three times longer than expected — a well-planned project only twice as long as expected.
36. Warning: dates in a calendar are closer than they appear to be.
37. Anything that can be changed will be changed until there is no time left to change anything.
38. There is no such thing as scope creep, only scope gallop.
39. A project gets a year late one day at a time.
40. If you're 6 months late on a milestone due next week but really believe you can make it, you're a project manager.
41. No project has ever finished on time, within budget, to requirements.
42. Yours won't be the first to.
43. Activity is not achievement.
44. Managing IT people is like herding cats.
45. If you don't know how to do a task, start it, then ten people who know less than you will tell you how to do it.
46. If you don't plan, it doesn't work. If you do plan, it doesn't work either. Why plan!
47. The person who says it will take the longest and cost the most is the only one with a clue how to do the job.
48. The sooner you get behind schedule, the more time you have to make it up.
49. The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression.
50. Good control reveals problems early — which only mean you'll have longer to worry about them.
Still, most of my career I just went by the term “engineer” without any specifications. This is how it all started. (Sing along to the Beverly Hillbillies tune.)
Come and listen to a story bout a man named Jed,
A poor college kid barely kept his family fed,
But then one day he was talking with a recruiter,
He said "They'll pay ya big bucks if ya work on a computer,"
Unix that is ... CRT's ... Workstations;
Well the first thing ya know ol' Jed's an Engineer.
The kinfolk said "Jed move away from here,"
They said "California is the place ya ought to be",
So he bought some donuts and move to San Josee,
Intel that is ... Big buildings ... Free coffee;
On his first day at work they stuck him in a cube,
Fed him more donuts and sat him at a tube,
They said "Your project's late but we know just what to do,
Instead of 40 hours, we'll work you fifty-two!,"
OT that is ... Unpaid ... Mandatory;
The weeks rolled by and things were looking bad,
Some schedules slipped and some managers were mad,
They called another meeting and decided on a fix,
The answer was simple, "We'll work him sixty-six,"
Tired that is ... Stressed Out ... No social life;
Months turned into years and his hair was turning gray,
Jed worked hard while his life slipped away,
Waiting to retire when he turned sixty-four,
Instead he got a call and they escorted him out the door,
Laid-off that is ... Debriefed ... Unemployed.
Dilbert's "Salary Theorem" states that "Engineers and scientists can never earn as much as business executives, sales people, accountants and especially liberal arts majors." This theorem can now be supported by a mathematical equation based on the following two well known postulates:
Postulate 1: Knowledge is Power.
Postulate 2: Time is Money.
As every engineer knows: Power = Work / Time.
Since: Knowledge = Power, then Knowledge = Work / Time,
and Time = Money, then Knowledge = Work / Money.
Solving for Money, we get: Money = Work / Knowledge.
Thus, as Knowledge approaches zero, money approaches infinity, regardless of the amount of work done.
Another song:
WRITE IN C ("Let it Be")
When I find my code in tons of trouble,
Friends and colleagues come to me,
Speaking words of wisdom:
"Write in C, write in C."
As the deadline fast approaches,
And bugs are all that I can see,
Somewhere, someone whispers:
"Write in C, write in C."
Write in C, write in C,
Write in C, oh, write in C.
LOGO's dead and buried,
Write in C, write in C.
I used to write a lot of FORTRAN,
For science it worked flawlessly.
Try using it for graphics!
Write in C, write in C.
If you've just spent nearly 30 hours,
Debugging some assembly,
Soon you will be glad to
Write in C, write in C.
Write in C, write in C,
Write in C, yeah, write in C.
BASIC's not the answer.
Write in C, write in C.
Write in C, write in C,
Write in C, oh, write in C.
Pascal won't quite cut it.
Write in C, write in C.
Of course, throughout my career I worked as an instructor or teacher. That is someone who talks while everyone else is sleeping.
At various points in my career I worked as a mathematician and a statistician. A mathematician is a blind man in a dark room looking for a black cat which isn’t there (Charles Darwin).
Statisticians is someone who is good with numbers but lacks the personality to be an accountant.
And now finally, I’m a retired engineer, but I still think of myself as a real engineer.
1. Real Engineers consider themselves well dressed if their socks match.
2. Real Engineers buy their spouses a set of matched screwdrivers for their birthday.
3. Real Engineers wear mustaches or beards for "efficiency." Not because they're lazy.
4. Real Engineers have a non-technical vocabulary of 800 words.
5. Real Engineers think a "biting wit" is their fox terrier.
6. Real Engineers know how to take the cover off of their computer, and are not afraid to do it.
7. Real Engineers know the second law of thermodynamics — but not their own shirt size.
8. Real Engineers repair their own cameras, telephones, televisions, watches, and automatic transmissions.
9. Real Engineers say "It's 70 degrees Fahrenheit, 25 degrees Celsius, and 298 degrees Kelvin" and all you say is "Isn't it a nice day"
10. Real Engineers give you the feeling you're having a conversation with a dial tone or busy signal.
11. Real Engineers wear badges so they don't forget who they are. Sometimes a note is attached saying "Don't offer me a ride today. I drove my own car."
12. Real Engineers' politics run towards acquiring a parking space with their name on it and an office with a window.
13. Real Engineers know the "ABC's of Infrared" from A to B.
14. Real Engineers rotate their tires for laughs.
15. Real Engineers will make four sets of drawings (with seven revisions) before making a bird bath.
16. Real Engineers' briefcases contain a Phillips screwdriver, a copy of "Quantum Physics," and a half of a peanut butter sandwich.
17. Real Engineers know that Halloween is really the same as Christmas, because OCT 31 = DEC 25. (If you _don't_ get it, then you're not a Real Engineer.) ((Write me if you want a hint.))
Real Engineers don't find the above at all funny.
Now, where’d I put my hat??
Originally written on April 7, 2011.
No comments:
Post a Comment