Code of Honour
I want to write about an element which makes my life as a developer rewarding and fun.
I found out that most people who I had the privilege to work with have pledged to an unwritten code of honour not unlike a Samurai’s. Let me spell it out:
Code and commitment
- My work is a reflection of my craftsmanship. I personally identify with its quality.
Once I have made a commitment to a project and delivery date, I will do my best to keep my word.
- It is a matter of honour to keep my commitment. I am prepared to make personal sacrifices to stick to my word.
- Sacrifices and commitment are voluntary and driven by intrinsic motivation.
Additional external pressure would be considered a breach of the code: I am already doing my best.
- I openly admit whenever I do not understand something.
Hierarchies are of little importance in a technical discussion.
What matters is the weight of an argument and not the rank of the speaker.
- My colleague’s time is at least as precious as my own.
- I read documentation and FAQs closely.
- I am not afraid to ask questions if necessary. I deliberate these questions.
If it helps my colleague, I will summarize them in a mail prior to asking.
- I take notes when someone gives me explanations. I avoid asking the same question twice.
- I do my best to help any colleague who asks me for help, no matter from which department, unit or location.
- My help is only limited by project pressure or if single colleagues push the boundaries.
- I make it as easy as possible for others to use my work through sound documentation and code structure.
Thus I minimize anybody’s effort who needs to use my work or step in for me in case of emergency.
I support new colleagues on a moral and technical level.
I have experienced this code mainly as a German SAP developer in Walldorf.
Yet I believe it is quite universal and not limited to one location or even company.
So why write about it?
After all, this code has a strong bias on duties which can make your life hard.
If you are the only person to adopt it, you are doomed:
Others would take advantage of your good-will and time.
Chances are and you would drop it very soon.
However once a group of people adopts it, things look very different:
I was lucky to work with teams where this was the case and I found work enjoyable and rewarding. I felt empowered, my working relations were based on mutual respect and high motivation.
Would I expect we all follow it 100% at all times?
I wouldn’t – we are human after all and different people give different weight to different points.
Yet I want to write this code down as an example and reference.
From a company perspective, I believe it has always been a strong contributor to efficiency and success.
Let us re-discover our strengths!
now, in the real world...
Nicely written blog..
On a lighter note; we can make everyone take this oath whosoever joins the organization or include it in induction program for new colleagues 🙂
since the first draft version I got to see I felt that the inherent message of this code echoes in my tortured developer soul. Knowing that there are people out there who identify with this code makes me feel much better.
I hereby declare to try my very best to adhere to this code 🙂
Many thanks for posting it in public!
sign the code and do the best I can, to follow it.
My personal code has one more important point under category communication:
I pay respect to my peers by paying my best attention to their efforts of explaining something to me.
(this is a lesson experienced so often in meetings where someone presents and everyone else answers emails, sends short messages or does anything else but paying attention)
An addition I would recommend:
To never believe that my learning will end with an attitude to always look for a better way.
Lastly, for me to commit can we soften the requirement to take notes to allow mental notes as an option? 🙂
Thanks for sharing.
My two cents:
This sentiment is normally very easy to live by. In most circumstances, the pressures of life, personal and work enable folks to act professionaly. It is the times when pressures are extraordinary that test our adherence to the "Code".
I commit to this sentiment...it is truely the right / professional / humane thing to do.
I would add the following:
KISS - Keep it simple because I'm stupid
Proactively share knowledge (Blogs, forums, speaking, conversations)
If I see someone struggling, I offer to help when I can.
But the commitment part to me is a little too optimistic - as in project's reality you will more often than not be faced with constraints forcing you to commit to deadlines you know you can't meet. And then you will be forced to trade either quality or "spare time" for keeping the timeline. I guess the employee survey goes to show that I am not the only one to get that impression. 🙂
Knowing you and your commitment level I would say that you do headline 1) on a voluntary basis everyday.
Sure, given your scenario that you happened to have a fixed deadline [Sounds even better in Englisch, who fixed the deadline - it's completly off the mark ?!? :)] then yes, it's either quality of free-time. That's when headline 1 comes into play... but remember, a samurai only fights for a worthy cause! 😉