Read some good books. The Psychology of Computer Programming and the Mythical Man Month are classics.

Learn something about UML and specification based design and also agile programming. They both have something to contribute and you have to strike a balance. If you try to specify everything up front, the design will be obsolete shortly after you start coding. If you jump right in and code, you'll have a mess you'll never be able to fix.

Be prepared to throw away code. There is no marxist theory of value in programming. Code is not worth the amount of labor that went into it. That's a sunk cost. If it's no good, then it's worthless. "But we put too much work into it to throw it out is never a valid reason by itself". This logic has destroyed many projects. If you're going to use agile programming techniques, you must be willing to sacrifice code. They won't work if you aren't.

"There's never time to do it right. There's always time to do it over." This is the place you don't want to be. This is also where management will try to push you. Don't agree to the impossible in order to preserve the peace and hope to make up time in the last half of the project. That NEVER happens. The first 90% of the project takes 90% of the time and the last 10% takes the other 90%.

Get your concessions up front. You have the most leverage with management at the start of the project. From then on the pressure will be on you to make givebacks. Hardly ever will you be granted more resources unless things are so hopeless that it's too late for them to do any good.

Never agree to a schedule where everything is assumed to go perfectly. If you see a perfect CPM schedule where all resources are 100% utilized, you can be sure it's unworkable. The reason is simple. The less slack there is in a schedule the more sensitive it is to small perturbations. You don't want the schedule that gets the project done the fastest. You want the fastest schedule that has a good probability of getting the project done. Somebody will get sick, quit, have a baby, get promoted, be urgently needed on another project. If that loss would create a disaster, you don't have a robust schedule. This is hard to sell to management, so you have to lie, and hide slack in the schedule. A good boss (who once had your job, after all) knows this and will wink at it.

Never pressure your programmers to reduce their estimates of how long something will take. They may just agree to do it, and then you'll be sorry. If you don't trust their estimates, you don't trust them. If you don't trust them why are they working for you? It's ok to try to redo the design to reduce the amount of work and shorten tasks, but why force people to lie to you? You could just lie to yourself and save the bother. Likewise don't let your boss lean on your staff to cut estimates. It's your job to take the heat and protect them. If you can't, you should quit before the inevitable project disaster drags you down with it.

Design for test. The QA and documentation is at least half the project and then there's years of support. You need to design features into the code that make this process easy. Try to find some good books about this (I don't know of any, but I haven't looked for a few years). Some of the basics are:

1. Fault simulation. You need to be able to inject errors into the system to see that they're handled correctly. Some errors don't occur often enough or conveniently enough to just wait.

2. result simulation. If something happens after a long sequence of screen I/O don't make some QA person spend weeks typing the same stuff into the system to make it happen. The system should be able to pretend. Screen capture is necessary sometimes, but it's a crude and inflexible approach. Try to work at a higher level.

3. Systems should be able to dump their state in some meaningful way. It's tedious to poke through this kind of information, but sometimes it's the only way to find anything. This goes triple for client server and networked systems. You have to be able to tell whether the problem is in the client or the server. This is absolutely necessary. See tagging data in 4.

4. In an event based system, tag your data and consider tools to organize the traces. You have to be able to match everything up so it makes sense.

5. If you are using a language that supports aspect based programming, use the feature. It makes writing debug code much easier.

As far as personal style goes, playing slightly stupid is very effective with the young arrogant types you get a lot of in programming, if you can carry the role. They'll tell you a lot more if they think they're smarter than you. The older more experienced staff catch on pretty quick, but they usually just smile and play along with it. Really good female managers sometimes use this style. The 25 year old hot shot talking down to the 45 year old manager with 25 years experience never seems to wonder how the manager could be stupid and still be where she is. They don't have to overplay it, because the hotshots snatch the bait right up. The manager will say. "Could you explain that again, I'm not sure I understood that last bit" - translation "I think your blowing smoke, how would you like a little more rope". It's great fun to watch. Harder for men to do though.

The best of my managers were always people who came up from the trenches.  Not necessarily the same trench, but who had worked at a low level and knew the kinds of tradeoffs and decisions that a programmer or sysadmin/sysprog has to make on a day to day basis.

Mutual trust is probably the best predictor has to how well the techie/manager relationship will work. The best managers would tell me the details of what they needed and ask for my help in wording and describing demonstrable milestones on my projects and developing realistic timetables.  Bad managers would write their own descriptions of "milestones" without asking input (or asking then ignoring it) and often in words that were purely subjective.

Oddly, at two of the best managers I've ever had were women.  Women are rarely great or deep programmers (I've met a couple, but they are rare!) but these women had worked in various other aspects of IT and worked their way up and really understood.  There seems to be something about certain kinds of women who understand practicality and at the same time can handle/deflect/diffuse political issues.

Beyond that, if you and your manager trust each other he/she will turn you loose to do your duties with minimal interference while holding the umbrella to keep the crap from up the hill from rolling down on you.