http://fh.rolia.net/f0/c1050/hit/post/6237273.html (removed?) + my comments
“A job usually involves many phases: investigation, brainstorming, design, implementation, testing and documentation. A quality job requires effort and time in every phase. However, when push comes to shove, many of the phases can be skipped. The problems will show up much later. By that time, nobody would care who’s to blame. And companies are more than willing to budget for these problems, in the form of increased support, more bug fixes, or even a brand-new system. You just have to be WILLING and ABLE to produce imperfect software.”
“The second important thing to managing work load is that you have to be the master of your domain, not your boss. This means you don’t tell your boss everything. And you make a lot of decisions yourself. Otherwise, you lose control.” — My GS team lead knows too much about my project. I tell him everything about my project.
“It starts from estimates. You know better than anyone else how long each piece will take. A hard piece to others might be easy for you. But a simple task might end up taking a lot of your time. Don’t tell your boss that you’ve worked on something before and can borrow a lot of code from previous projects.”
“The same applies in the middle of your project. A seemingly complicated piece could turn out to be smooth sailing. Yet a small issue could bog you down for many hours. Again, don’t tell your boss you finished something in an hour which was budgeted for half a day. But do tell him that a bug from another team cost you many hours unexpectedly.”
“What do you do when you see something wrong in the requirement? Or something wrong with other people’s work which you depend on? If you’re pressed for time, act as if you didn’t see them. Act like a fool. You may be punished for missing your own deadline, but you’re unlikely to be punished for not spotting other people’s mistakes.” — By not reporting the issues early, project will suffer but you will not, but avoid making your boss look bad — try to give him a scapegoat. Project will suffer — project will need more time, and the reason is other people’s mistakes. You expand the impact of their mistakes to get more time for yourself. Conversely, when your mistake affects them, they might do the same.
“What do you do when deadline approaches and you discovered a big hole in your work? Again, act like a fool. Act as if you didn’t see them. You hand in your work. And a week later, people would find issues. But that’s normal. Nobody’s perfect. You and your boss get punished for missing deadline; but neither(???) of you would be held responsible for (non-critical?) bugs. Rather you will be given new budget to fix things, probably after a relaxing break in the sun.”
“Every decision you make affects your schedule. Be flexible. Be creative. Be able to accept imperfections. Be a liar if need be. The important thing is to look good, not to be good. Image is everything. And you can cut a lot of corners without affecting your image.”
— GS Slogan says “Tell your manager the bad news early”. If it’s your mistake, then decide if he will find out you were hiding it. Some managers periodically ask “Any problem?” Often he can’t be sure you were knowingly hiding problems — you could act like a fool.
— There are different bugs and different levels of impact. Manager may say some functionality is important or some time line is important, but question them in your head. It takes a lot of observations to figure out which ones are really important to your manager’s bonus. Many delays and missing features are manageable or expected.
— My GS team peers know what bugs are tolerable to the manager. If manager must explain it to users and other teams, then you know it’s a visible bug. This knowledge comes from experience. However, initially you need to do some quality work to win trust.
— In fact, the best GS (and other) team members often contribute non-trivial bugs, partly because they are more productive and change lots and lots of code quickly.