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?"
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
...use the ice-pick on a piece of hell for my drink.
You can't make everyone happy, nor should you try.
Delegate - upwards, sideways, anywhere - everything that is not your responsibility: business analysis, requirements definition, project planning, test planning, and steer clear of the politics.
Insist on written documents, version controlled, reviewed and signed off, to show your supervisor what the constraints are.
You have to deliver to the company's scheduling needs, and you need to keep the quality as high as possible.
Anything you can add at the technical level is only a bonus, unless you can explain it (in tech terms) to the business as a benefit to them, and they understand, and care.
Now, for the important question:
How can you make YOURSELF happy?
(otherwise, what are you doing it for? - and don't say paycheck, 'cos there's a balance and money ain't everything)
include $sig;
1;
Your manager was right on both counts.
1) Although you know how long it will take you, you do not know how many other projects will be multiplexed into your time. It is your manager's job to decide how long it will take you to complete a task for a client, regardless of how long it will take you.
2) You gave away your time for free, you released code without authorisation which is added risk to your employer.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Best advice ever.
Usually you want to please your direct supervisor. If you do what he likes, the only person with direct knowledge of your work says good things about you. If you don't please your bosses boss, it's not you that will be taking heat.
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.
Well, really the manager made the mistake of taking the engineer in there in the first place. The second mistake from the manager is not taking him in "the room" and laying out a plan of action.
Ultimately, it's ALWAYS management's fault.
Yes, Always. Always, always, always. Remember: It's always management's fault.
Did the programmer slack and not deliver the program on time/at all? Management should have motived him or replaced him. It's always management's fault.
Therefore: It's not the engineer's fault, ever.
"Piter, too, is dead."
The software development triangle states that features (and, I suppose, the overhead of developing to whatever standards your managers happen to define as "correct") are balanced against resources and time. If you want to give a programmer less time, give him more resources (money, more developers, etc.) or accept a less sophisticated program.
:)
It sounds like your managers aren't respecting this principle, and perhaps the only advice I can give you is to talk to them about it and/or start looking for a job elsewhere
Well yes. But a manager should have made expectations clear before bringing a subordinate into the room. If THAT didn't happen, then the manager is at fault.
Those that suggest software (or any other product) should do EXACLTY what is contracted and NOT ONE SINGLE THING MORE are being, I think a little short-sighted. Yes there are IP issues, but those can be addressed with a bit fo boiler-plate legaleze -- this feature is provided as is -- no warrany whatsoever -- it is not supported, yada yada.
But if I am the customer, and a I get a bit more than I expect, I'm a VERY happy customer and not only do I put this company at the top of my list of preferred vendors, but I'll spread the word to others. The company that goes the extra mile will get more business in the end.
Nuttles1:
p2sam: You should report to one mananger, and one manager alone... Well, in a perfect world, that's how it should work. :)
Just be completely honest and forthright in all your communications.
Suppose you have
Then your emails would read like:Slashdot is really the wrong place for this sort of discussion, but here goes: It sounds like you're working on a product that doesn't have a product manager. The way it's supposed to work is that the product manager decides what goes into the product and coordinates with the developers to come up with a realistic schedule. Anyone who has a request should be talking to the product manager to get it into the schedule.
Clearly you knew what you were doing... this time.
IFF you can do this 95% of the time then obviously the smart thing to do is find yourself a salesperson and go into the consulting business doing this type of work.
As soon as you have to start paying the salary for the salesperson, the overhead of running your business and doing the tapdance of handling more than one client at a time while simultaneously trying to land more work for the near future you will probably understand exactly where your boss was coming from.
( tap tap tap...shufflin' off to Buffalo...tap tap )
A manager shouldn't have to enumerate all the things that an employee is not allowed to do - they should be intelligent enough to know that they should check with someone before embarking on extra work outside of the scope of what they were assigned, especially when a client is involved.
I doubt that the engineer took classes in how to screw over the customer, while I'm quite sure that the manager did. The engineer is concerned with building a good product and takes pride in that. So, while the manager is trying to think of ways to get more money out of the customer while giving them as little functionality as possible, the engineer is trying to figure out how to give them the most bang for their buck. See the disconnect? That's why the manager needs to make certain things clear before a meeting like that. Manager thinking is not at all intuitive to most engineers.
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
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.
In my last job, I was in a situation where I had two bosses. Boss A wanted me to to do my job using method X. Boss B wanted me to do my job using mathod Y. I liked and respected both bosses and could see the benefits of either method A or B to complete my task. When bosses A and B were in the same room, violent firestorms of loud cursing and office furniture throwing ensued. I completed my assignment using method C, an ugly amalgam of methods A and B because I wanted to please both bosses.
I've been unemployed since then. Pick one boss and please him or her.
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.
The real story is rather more complex than that.
;-) counts the hours they spend on a project.
;-/
Engineers *with experience* are good at estimation. By the time you've got that experience, chances are you've been in the business 5-10 years and you've got the seniority to not have the kind of grief the OP had.
My personal experience of myself and everyone else I've ever worked with though, for the last 7 years since uni working in embedded software, is that *everyone* sucks initially. Without exception. Until you get into a job, you're not used to 37.5 hours *and* making deadlines. Need to make a uni assignment? Work into the night, no worries, and make up the sleep the next couple of weeks. No student anywhere (unless they're some kind of freak
That all kind of falls apart at work, where management frowns on employees working themselves into the ground short-term and working less productively overall. It also runs into the notorious over-optimism of young engineers, who assume that because they've solved all tasks quickly so far, that every other task they'll see in the next couple of years will be equally easy. Throw a 200-page spec at them, and expect a response of "yeah, 6-8 weeks, no worries". And finally, they forget that docs and testing are also part of the job - typically they never had to do that at uni, so they only count the coding time. The job of the manager and/or senior engineer is to inject rationality into estimates from people who can't estimate themselves.
Basically, estimating is like driving a car - the more you do it, the better you get. Initially you don't know how, and basing project quotes on estimates from a new grad is like putting a 16-year-old into an F1 car and saying "go for it" - the crash is inevitable. A smart manager will get estimates from everyone (so they all feel equally important), factor in reliability and how long *they* think it'll take (and how long their senior engineer thinks), and use those numbers instead. A *really* smart manager will monitor how long it actually took, so his team can find out what their over/under-estimating tendencies are, and improve in future. Sadly there aren't enough of the former, and even less of the latter.
As you say though, the problem is managers who say "oh no, that's way too long, cut it by 75%". If they have a basis for saying that, then fine - some inexperienced engineers swing the other way and estimate months for a 2-week job. But if they've no technical understanding then they're just as inexperienced as a green engineer, and just as much of a liability.
Grab.