Slashdot Mirror
How Can a Programmer Make Everyone Happy?
Nuttles1 asks: "Ever since I became a professional programmer, 4 years ago, I have struggled with giving my superiors everything they want. For instance, I have a programming supervisor that stresses correctness in programming first, amount of time needed second, features third, but I also have upper management stressing features and amount of time needed first and correctness of programming a distant second. The nature of my job requires pretty strict deadlines so time is not very variable. So, things get done in a way that fits the time allotted. The problem is that I don't make my direct supervisor happy because of the time constraint shortcuts in correctness must be made. The other problem is that, because I perform within the time constraints, they think that the time constraint can either stay relatively the same or that they can be squeezed a little more. Upper management also expects the advantages of having a strict programmatically correct program (code reuse, loose coupling, ease of maintenance) and are at loss when things are less then perfect after the initial release. It doesn't seem like a programmer can come out ahead. I have read many books but they usually have a utopian viewpoint or view time to develop as a variable. In real life, how do programmers handle this situation?"
Well, from your narrative I see you've landed the ultimate professional progammer position: one where management doesn't listen, tries to squeeze deadlines, and thinks code more than anything else has to be correct (the unfortunate thing about that being your management, the least qualified to say, probably defines correct.)
And, forgive me, I can't help but notice but the word client or customer is not mentioned even once in the narrative which indicates an upside down world for delivering applications (not all that unusual, but still upside down).
Also, you mention superiors, try to be a little less humble, they're likely not. And, you talk about "upper management". When upper management has their uncalloused little fingers all the way down to your level in determining quality, ....
Ultimately, unless you have some strong ties, or visions of fast advancement you'd be no worse off if you looked around a little to see if there is someplace that seems a little more attuned to the real world and a little less pedantic about "coding".
aside: (but related) I first encountered how crazy a world it could be with my first big assignment. I had to sit down with my manager, and our client. The client described what they wanted, and I gave a thumbnail estimate, apparently to the surprise of my manager. Surprise number 1: my manager took me into "the room" and told me never to give an estimate to the client without his approval. (I might agree with certain aspects of this, but I was confident of my estimate and had sort of figured it was part of my responsibility.) He wanted me to double my estimate, and that was what we would base our charge to the client on.
I finished the project ahead of my original estimate -- adding enhancements and extensions to some software we'd purchased from a sister telcom. When I delivered it to the clients, ahead of schedule, I pointed out that part of the original output of the original program was just garbage, i.e., there was no code written around that output, and it had no correlation to the rest of the report. The client knew already and told me they always just ignored that part of the report. I asked if they needed or wanted that part of the report, and their eyes just lit up. So I offered to deliver yet a different version of my code which included a fix for the broken part of the old application. The client was ecstatic, a glowing letter ensued.
My manager took me to "the room" again. I tried to remain calm, waiting for the accolades, perhaps even a bonus? But, he pointed his finger in my face and said, "Don't you ever deliver more to the client than you say you will!". Stunned silence.
This is not so much a programmer problem but just a business problem; also known as a people problem. Just substitute programming with any other job description and you have the problems everyone deals with on a daily basis. There is no right or wrong answer only the relationships you have to deal with.
Quality Hosting e3 Servers
Insist the "higher-ups" go through your direct boss. Not every boss will protect you this way, but unless it's a really small startup, they should, IMO.
The clearance system sounds logical. It is not. It is completely arbitrary. -- John Bolton
Here's the thing, just deal with it for awhile. Make some money, and then leave for another job that has smart people in charge. Wannabe programmers that are in management just screw everything up cause they think that if they follow the one guideline they remember from a 900 page development book they read in 1983 while studying COBOL, that everything will be perfect. Chalk it up as experience, or "paying your dues", or if you're past those points in your life, deal with it or move on.
Now of course, if you're working on some important systems like aviation, military, or any of the MMORPGs I play, then shutup and get back to work.
After 10 years in the industry, I've got the following three methods:
1. Do everything everybody asks you to, even if you personally think it's contradictory. Works in companies that have a strong chain of command, but results in code you would never want to include in your interview portfolio. And gets you targeted for first layoff.
2. Go your own way, but do plenty of software engineering to back things up. Gets you targeted quite often for layoff, but since you have the numbers, you rarely get laid off- this method has resulted in up to two years in the same job for me. Results in code you can be proud in, but you'll never meet a deadline, and that will eventually get you fired, so to give yourself extra time always multiply all estimates by 4 (Scotty school of engineering).
3. Give up, and offshore your job. Everything gets coded exactly to spec, even when the specs make no sense, and nothing gets done right- but at least you'll end up doing what you're told, until your bosses find out, and then they cut out the middle man (you).
In other words, I've yet to find a winning method in the situation you describe.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
"I don't know the key to success, but the key to failure is trying to please everybody."
Please the boss that can give you the raise and fire you.
include $sig;
1;
Sorry, just thought this fits too perfect:
Peter: It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime, so where's the motivation? And here's another thing, I have eight different bosses right now.
Bob: Eight?
Peter: Eight, Bob. So that means when I make a mistake, I have eight different people coming by to tell me about it. That's my only real motivation is not to be hassled, that, and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.
The ratio of people to cake is too big
Lets get real here. The stiuation is bad, your'e not in a position to change it. Ask yourself who writes your performance reviews. Talk to them. Find out what they want from you. Give it to them. Wait for your review and then either move up or be prepared to move away.
Sometimes you just have to be your own best friend.
Surprise number 1: my manager took me into "the room" and told me never to give an estimate to the client without his approval.
My manager took me to "the room" again. I tried to remain calm, waiting for the accolades, perhaps even a bonus? But, he pointed his finger in my face and said, "Don't you ever deliver more to the client than you say you will!". Stunned silence.
This is just atrocious management.
A good manager would have practiced [over and over again] the interaction before he ever let you meet the client face to face.
For example, he would have stressed things like
And then he would have gone through practice conversations in which he pretended to be the client, and he coached you as to what to say and what not to say, and how to hem and haw your way out of making any firm commitment [until the "correct" answer could be cleared by accounting].Your manager not practicing a client site visit like that with you beforehand, and then admonishing you afterwords, would be like a football coach not teaching his playbook to his players during practice [or never even showing them the playbook in the first place], and then yelling at them after the game because they were clueless on the field.
That's not necessarily true. At least, not the way you explain it. Deadlines can be real "dead lines", in that if you miss the deadline you're dead (or your project, anyway). However, don't forget that time (deadlines) is just one part of a triumvirate of quality, time, and features. If time is fixed (you're on a contract with a specific end date, you've publicly promised to ship on a certain date, a different team has publicly promised to ship on a certain date and your project is a requirement for their shippnig, etc), then something else has to give. Enlightened managers will cut features in favor of quality. Unenlightened managers will cut quality in favor of features. The only way to deal with this as a front-line developer is to make sure you're getting pressure from only one place -- your direct manager. If your manager's manager is dictating something else, you have the right to tell him or her to go through your own manager (in a diplomatic sort of way, unless you like being on the shitlist). Of course, you can go the other way, too. If your manager is setting unrealistic goals, or is damaging the project (focusing on features instead of quality), you can and should go to their manager and discuss the problem. Either way, you can't perform two contradictory actions at the same time, so you need to speak up.
You must not work in the commercial world. Looming deadlines and a list of promised features often means you have to sacrifice some quality. Usually you'll do so with the intention of cleaning it up in V.Next, but the vicious cycle of less time and more features conspires against you. The best you can do is argue in favor of doing things right, or at least taking some time to do a postmortem to evaluate why quality had to be cut and try to get time to clean things up. That's a problem with shrink-wrapped software, though, because nobody's going to buy a new version just because you cleaned up the architecture (assuming the previous version works well enough already). So you're back into doing features rather than fixing brokenness. While it sucks, you can at least take some solace in knowing that you wanted to do the right thing but couldn't because of someone higher up the chain.
In the broadest sense, you control your future. But more pragmatically, it's really difficult serving two masters. You'll be happier and better serve your career growth by using the chain of command to work for you. Make sure you're only taking tasks from your direct manager, and don't accept any tasks that didn't come down that chain. There are times when you can and even should take tasks from people other than your manager, but when crunch time is on and it's a Do or Die situation, funnel those requests.
Finally, evaluate why there's no time to do things right. Are you giving bad estimates? Are your estimates being changed by others besides you (people who aren't going to do the work)? Are your estimates assuming a perfect working environment? (if so, adjust your estimate to include context switching time to deal with interruptions, or lobby for "dark days" where you can turn off email, shut your door, and stop any interruptions so you can get a full day's work done.) Maybe you can change some things. Maybe you need to change your own view. Maybe you need to change jobs.
I explained the problems you're facing to my wife.
She said "How long has he worked for Microsoft?"
After giving it some thought, she suggests "get some balls and ask your boss exactly 'what do you want?' so that you can cover your ass, preferably by email and when the higher smucks express displeasure, hit the print button."
She goes so far to say you should include the higher smucks in that discussion of how it should be done. Carbon copy them in the email if you're emailing.
Disclaimer: I am posting her suggestion because she has been in this type of situation and came out well. Personally, I see a danger of tanking evaluations and having to keep an eye out for the next job.
B) Eliminate all the stupid users. This is frowned upon by society.
Talk to your line manager. In a private meeting, explain the compromises you're having to make in your work. Explain that the code you're being forced to release is unmaintainable, is prone to be bugged or poorly-structured because of the time constraints being forced.
Explain a compromise where you get some of the time you want in return for some of the code quality you want. You'll never get all the time you want but, if you can convince your boss that it's going to be of overall benefit, you might get enough.
Most importantly, if the shit hits the fan and your product comes back to you, make sure you're absolutely realistic with management about why this has happened. Yes, the code was sub-quality. Yes, the design was insufficient. Yes, it's management's fault on both counts for not allowing enough time for the proper running of the project.
One of the main problems is that a typical lifecycle (specification, design, implementation, testing) makes no sense to management. Even a technical manager will try to rush the specification and design so they can have demonstrable progress - something to show the client, even if it's not been thought through. And, as soon as the product looks complete, they'll want to get it out where it makes money, regardless of how thoroughly it's been tested.
Educating your superiors about the reality of these things is hard work. You might have managers that will - slowly - learn, in which case you may make some progress. Alternatively, look elsewhere: it's one of the most subtly self-destructive things, to be stuck in a job without being given the opportunity to do it well. Find somewhere that gives you that freedom.