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.
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.
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.
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.
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.
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.
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.
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.
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...
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