Oath:

A solemn promise, often invoking a divine witness, regarding one's future
action or behavior.

The oath, it sounds serious. Well, for some it is. As it should be. Doctors, lawyers, barbers, and many other professionals all have their own self-imposed oaths they they follow the entire course of their career. The good ones stand by them. Those who don't and cause harm to others, are disbarred, or rejected and it becomes difficult or impossible to find work.

So what's your point?

Well, Robert Martin and others have talked about in videos, and even tried to push this on various levels. Martin has a video that brings this up called The Scribe's Oath. I agree on a lot of this, especially the oath itself which he talks about in the video. But the act of self-regulating our industry would be far more difficult. And would bring many complexities that some may not want. While he does say we should do this before there is a major event that causes the govt. to force us into regulation, and I agree, that is something that will be much harder to do in this industry compared to others.

Unlike doctors, lawyers, and others; Software programmers can also be in the medical field, work with laws, politics, the stock market, startups, and everything in between. So I am not even sure if it can be regulated. But there is one way that we, as a society of programmers could agree on, is a set of standards for ourselves. While we may not be able to have actual regulations very easy, taking a stand and working against a code of ethics can say a lot for yourself.

What if my employer asks me to do something questionable?

Well that's the problem. I think many of us have been in this position. But remember, they hired is to build and work on their software. In a way, they hired us to say No. If you were fired for not writing immoral code, is that someone we want to work for? I would'nt. I've been in that situation and when I was a young programmer, I felt the same way but I didn't want to lose my job. Suffice to say I wasn't working there for much longer.

Volkswagen CEO Michael Horn in 2015 (Resigned in 2016) was quick to blame programmers when he was caught in a scandal. So your employer may not always have your back. Which is why i feel like it is so important to live by a code of standards. While this list was pulled from Martins talk linked above, I totally agree with it. This is not to say it may or may not change over time.

As far as I am concerned I am a professional. I was hired to do my job with the expectation that I would write code to improve my employers software, business, and their bottom line. So as a professional, this is what I will do my best to stick to. And I openly welcome anyone to call me out if they witness me not sticking to these codes when in a professional setting.

1. I will not produce harmful code

This can be up to interpretation for some. And that is ok. It also may depend on your career. What if you write software for the military in missiles? I think the main point is that the software itself will not knowingly release defects that cause harm to it's users, or even future programmers by making it hard to understand.

2. The code that I produce will always be my best work

You should always write your best code in that time. All programmers can go back to something they wrote in the past and wonder why they would write such crappy code. But in that moment it is written, you write that to the best of your ability.

3. I will provide with each release a quick, sure and repeatable proof that

This pretty means testing. You should always test your code and make sure it is reliable, repeatable, and as idempotent as possible.

4. I will make frequent and small releases

This helps improve both your, and your teams productivity and helps ensure less issues crop up down the line. More productivity, means more features, better programs, and happier customers.

5. I will fearlessly and relentlessly improve at any opportunity, will not make the code worse

You should always look to improve both your code, and the code you work on. There will always be bad code others have written. And the best way to remedy that is to leave things better than you found them. It's not always easy and sometimes requires larger discussions about rewriting portions of code. But you should always strive to improve what you see and write.

6. I will keep productivity my own and my team high, I will do nothing that decreases that productivity

You will do your best to keep the productivity of you and your team high and will not do anything to sabotage that.

7. I will continuously ensure, that others can cover for me and that I can cover for them

Spreading the wealth of knowledge. Often times, this can be as simple as pair programming and showing others how to build what you make. The larger your team is that does the same thing, the easier this is.

8. I will produce estimates that are honed both in magnitude and precision, I will not make promises without certainty

This is especially true with agile practices. Even though your project manager may not like it, often times the best answer on how long a task will take is simply "I don't know". This may mean it need to be broken down into smaller chunks. But you shouldn't ever lie about your estimate. You should always be trying your hardest to asses this the the best of your knowledge and everyone will get better over time.

9. I will never stop learning and improving my craft

First, you should not be learning new things at your employers expense unless that is an expected part of your jobs. Such as interns, Jr. devs, and learning a code base. There are other cases as well. But you should not be learning and improving your skills that do not pertains to your employers interests. As long as you are in this career (or any other) you should always be looking for way to improve your craft.

Do you agree with these guidelines? What would you change? What would you add? Let me know in the comments or on twitter.