I'm making a set of precepts that I'm going to try and stick to from a professional engagements perspective. These have been very much influenced by Uncle Bob - especially his keynote for EclipseCon 2010, which provided the inspiration to put these together in this form - and of course by the many mistakes I've made in the past, which is what we call experience. So, in no particular order:
If you haven't communicated with a user of your software in over a month, you could have departed the Earth for Epsilon Eridani and you wouldn't know.
When you hear yourself saying well, I hope we'll be done by the end of the week, then you are officially on the way to that state known as doomed. If you are invoking hope, trouble is not far away. So, endeavour to destroy hope at every turn. You do this with data. Know where you are - use an agile style of process to collect data points. Iterate in fine swerves that give you early notice of rocks in the development stream.
Be constructive about it, however. You should know what you want to get out of the meeting. If it's moving away from what you are expecting, contribute to getting it back on track. It won't always go totally your way. If you can't retrieve it, then make your excuse and leave.
Pick your own example here. Note that restrictions can also take the form of a big shouty man roaring the effing developers don't have effing time to write effing tests! (true story that).
This is pretty simple on the face of it. One theory on human motivation includes three demands - autonomy, mastery, purpose - that all need to be satisfied to a certain degree before one is effectively motivated (see Dan Pink's TED lecture). If there is no plan, or the plan stinks like a week-old haddock, then the purpose element of your motivation is going to be missing. Would like to earn lots of money, work with fantastic technologies and yet have your work burnt in front of your eyes at the end of the month? I wouldn't.
Without extensive practice, humans find it difficult to separate their emotions from discussions, especially when there is something potentially big at stake. Just look at the level of fear-mongering that politicians come out with to influence voters. There will be some shouting - expect it - but it's not right if shouting is a regular occurrence.
How many times have I done this already over the last eighteen years? Ugh.
No making a mess - your Mom taught you that. Stick with your disciplines. Don't let any one else beat up on the software either. It's your software too, and hence your problem if it is abused.
Intellectual violence is a project management antipattern, whereby someone who understands a theory, or a buzzword, or a technology uses this knowledge to intimidate others that do not know it. Basically, it's used to shut people up during a meeting, preying on their reluctance to show ignorance in a particular area (this reluctance can be very strong in techie folks). Check out number nineteen in Things to Say When You're Losing a Technical Argument. Stand up to this kind of treatment. Ask for the perpetrator to explain his concern to everyone in the room.
I know that if I am learning new technologies, I can do it best provided I have time to sleep and time to exercise. I also know that my learning graph is a little like a step function, with exponential-style curves leading to plateaus. I know when I am working through problems and my brain suddenly tells me to go and get another coffee, or switch to some other task, or go and chat to someone, it means I am very close to hitting a new understanding plateau. So I have to sit there and not give in :) I also know that I need to play with tiny solutions to help me too.
This should be easy for you - if you are tired, you are broken. Don't be broken and work on your code. Go somewhere and rest. Insist on it.
Needless to say at some point in the future this post will come back to haunt me I am sure. But I'm hoping that if I produce a little laminated card with these precepts on it, keep it in my wallet, then I'll at least not lose track by accident.