History became legend. Legend became myth. And for one hundred and sixteen months, this following blog post passed out of all knowledge.
However it turns out Google did actually remember and I found my old blog again, and with it, a post that I reproduce in mostly its entirety here.
Warning before you begin: this post mentions Uncle Bob, who has become a bit of problematic figure around these parts. He did give a very good talk at that EclipseCon show in 2010, though.
Oisín’s Precepts Version 1.0.qualifier May 2010
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:
Don’t be in so deep you can’t see reality. 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.
Seek to destroy hope, the project-killer. 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.
When the meeting is boring, leave. 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.
Don’t accept dumb restrictions on your development process. 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).
There must be a Plan and you must Believe It Will Work. 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.
Discussions can involve some heated exchanges. That’s ok, but only now and then. 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.
Refuse to commit to miracles. How many times have I done this already over the last eighteen^h^h^h^h^h^h^h^h twenty-seven years? Ugh.
Do not harm the software, or allow it to come to harm through inaction. No making a mess – your parents 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.
Neither perpetrate intellectual violence, nor allow it to be perpetrated upon you. 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.
Learn how you learn. 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.
You have limits on overtime, know them. 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.
Narrator’s voice: He lost track by accident