|
|
Maybe you should get some bifocals[^] then? 
But seriously, customers who significantly change what they want after you've already written what they previously said they wanted are annoying.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
... though for the past 24 years as a freelancer, part of my role is to make sure expectations are clear at the outset. If there are still unrealistic expectations, it's my fault in most cases so...
OTOH when I was a permie, (or a contractor on a job I didn't have much control over) things were very different... 
|
|
|
|
|
I've always worked at a company instead of contracting. My first job had unrealistic expectations and high pressure to do the impossible. After that I realized that part of my job is to estimate well and stick to those estimates. This type of thing is described in "Software Estimation: Demystifying the dark art" and "The Clean Coder" pretty well.
So even at a company it's still our job to manage expectations and be clear about what can get done and with what features.
Elephant elephant elephant, sunshine sunshine sunshine
|
|
|
|
|
loctrice wrote: realized that part of my job is to estimate well and stick to those estimates
Sadly it isn't always you that is in control of those estimates, even if you estimate well and stick to them.
Take my own experiences, I was still very green at my first job and did not estimate well, usually my 40 hours should have been 50 or 60. To make it worse the conversations usually went something like this...
Me to my manager: It'll take 40 hours.
My manager to the director: It'll take 30 hours.
Director to customer: It'll take 20 hours.
My manager to me: You said it would only take 20 hours, why isn't it done!?! You need to work late every night and weekends until it is done ASAP!
Me to my manager: ...What? I told you it would take 40 hours, here is the email where I said just that.
My manager to me: We promised the customer it would be ready in 20 and now we are behind schedule! As I gained experience my estimates got more accurate overall plus I learned to pad appropriately knowing how much management would reduce them when talking with the customer. That came back to bite me in the ass at the next job which was just the opposite. The PM would pad 30% on top and the director would pad another 30% on top of that.
|
|
|
|
|
I paraphrased the message of 2 books. The exact scenario you've outlined is covered in at least one of those books. I think both actually.
Reply:
No this is not my fault. I gave you my best estimate. No one can do double the work in half the time, and the amount of overtime you're talking about is going to slow things down and produce poor results. Let's talk about what features we can get done in 20.
I would have turned that conversation at the point where the manager volunteered me for overtime so it could get done ASAP!.
I do get what you're saying though. In my first job it was much worse, and I didn't do my part. I didn't say no, and agreed to things like lots of overtime and unrealistic expectations.
Elephant elephant elephant, sunshine sunshine sunshine
|
|
|
|
|
Take a lesson from Star Trek's Scotty: always multiply your estimates by a factor of four.
How else can you maintain your reputation as a miracle-worker? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
The clutter of useless information in MicroSoft's Help system. It's also slow. Google has declined in usefulness as well.
Fortunately I still have all my printed Visual C++ manuals (6 volumes) which provide a starting point for finding information.
Since I work at home I can listen to the music I like and have meetings with just my cat in attendance. When I worked for pay, I also resented status meetings.
Joan F Silverston
jsilverston@cox.net
nhswinc.com
|
|
|
|
|
Everyone thinks "I'm a brilliant programmer", it's everyone else who sucks.
|
|
|
|
|
Until you find code riddled with magic numbers, severe compiler warnings and terribly designed (everything has side effects).
Then you can safely assume it is sh*t.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
- A screen shot with stuff scrawled upon it are not requirements.
- Product owner who have no idea what the business needs are.
- Email is not a valid change/bug tracking device
- Bug reports without steps to reproduce
- Bug reports without a user's expectation, just "this seems wrong"
- Coworkers trying to defend the indefensible
- MVC is "too hard"
- ADO.NET is superior to EF
- "We've always done it this way"
etc etc etc. And this doesn't even touch upon my own stupidity.
|
|
|
|
|
Nothing bothers me more than thinking it's finally done, only to find out there's more.
|
|
|
|
|
Interruptions: A couple of years ago I was working on an issue for a customer that was irate, and it wasn't going well. I finally put a sign up outside my cube that said "Unless it is ON FIRE don't interrupt me!", with the full approval of my boss.
Meetings: I routinely decline meetings unless the organizer is above me in the food chain. Then I talk to my boss and see if he'll go in my place (if he's not already invited). Once I started taking this approach I reduced my meeting schedule from 2-3 a day to 1 or 2 a week.
Loud environment: Easiest of all: A pair of Sony MDR-V900[^] headphones.
The only issue I haven't found a simple solution to is that of crappy legacy code. My group has been 'reduced in force' from 17 down to 5 over the last six years. All of us who are left have acquired responsibility for products or components created by someone now gone. Some of it is good and easy to maintain. Some of it is not.
Software Zen: delete this;
|
|
|
|
|
When I worked for large clients, or as a permie, I simply implemented a rule - if you don't send me an agenda in advance, I'll assume the meeting has been cancelled.
Saved me a lot of time and did actually have some effect in reducing meetings (and certainly the number of meetings I went to). It was surprisingly quick when meeting conveners chased me up to explain my non-attendance; the majority (mainly those in senior positions) got the point fairly fast.
|
|
|
|
|
Solved the problem. Initially, it was just starting to fall asleep while the blitherers did their thing. That was almost like not being there.
Then a better solution occurred: Unabashedly ask questions that pointed out the stupidity of the proposed solutions (which, although being discussed were already forgone conclusions). Asking such questions and (time and again) turning out to be right made me persona non grata at nearly any meeting.
Try it - you'll like it.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Worked in a cube that had a glass panel in front of the monitor and the person would use a Back Scratcher.
|
|
|
|
|
I have the following two experiences, all with Asian cultures; I am also Asian, an Indian.
1. With Japanese counterparts: In a discussion, I heard the word "cross", and was wondering what this meant for at least a day. Then I realised it is a "class" as in C++ class.
2. With Chinese counterparts: In a discussion about Mechanical CAD software, heard the word "ulib". After two days, realised that it was "rib", as a ribbed mechanical structure.
Some cultures use the letter "r" for the letter "el" and vice versa, and this can cause confusion.
|
|
|
|
|
They just don't get what I ask them again and again.
|
|
|
|
|
When that happens, I have a less-techie co-worker review my emails and help dumb them down.
Outside of a dog, a book is a man's best friend; inside of a dog, it's too dark to read. -- Groucho Marx
|
|
|
|
|
I've found that with some clients I have to explain the issue and ask them the necessary questions; then at the end I put, in one very short sentence, what I need them to do; and highlight it in bold.
e.g.
In order to calculate xyz I need to know whether the percentages of abc are pro-rated across the entire date range when either end is before or after the start/end date of the whatchamacallit's activation period. Let me know if rates should be pro-rated.
I summarise by saying "I'll await your response to the [n] items highlighted above".
Never ask more than 4 questions in such an email. If the issues are related to each other, send separate emails. (Otherwise the respondee answers one question and thinks they've covered the subject!)
|
|
|
|
|
Ultimately the thing that bothers me the most is the tools. Not that they aren't vastly better than they used to be, but they are still so far from what they could be. And, since they are what I need to get my thing done day in and out, any lackings will tend to be magnified in terms of frustrations I experience in the process of coding.
Explorans limites defectum
|
|
|
|
|
Particularly from when I wrote it 6 months ago and didn't have a clue how this new library was supposed to work. Now I have a better understanding of how the library works, just not how to improve my barely-working code without rewriting all of it...
|
|
|
|
|
I know what you mean
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
