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.
Top comments (9)
To be honest, I disagree with #2. It is not always in the best interest of your customer or your employer to do your absolute best every time. There are times when it is important, and times when it is not. When it is not, the price you pay is the opportunity cost of everything else you could have improved during the time you were polishing that unimportant detail. Of course, every dev thinks they make the right balance of speed vs. perfection, yet every dev does it differently. So it is best to get a second opinion from someone with a little different outlook than you, whenever you go far toward one or the other.
I could agree with that. There would be a balance. If in a given case doing your best prevents you completing something in a timely manner (#4 & #6) then you would have to use best judgement. I don't really touch on that as well as I should. But I believe this to be a valid point. But it also has to be taken into account with the others.
I suppose it could be a matter of how you define doing your best. Best possible code vs. applying yourself to the best of your abilities.
Yea personal judgement is part of it too I think. As long as overall you have your best intentions in mind and strive to do your best. There will always be some variation in that depending on the person.
I've come across this before and...well...this is awful. I have so many problems with this "oath" that it's actually hard to tell where to start.
First, some kind of oath or code of ethics is absolutely nothing new. Just about every professional computing organization has one - the IEEE, the ACM, the Computer Society of India, the Hong Kong Computer Society, the National Society of Professional Engineers, and the list goes on. Sometimes, graduates of computing or engineering organizations may choose to take the Pledge of the Computing Professional or the Obligation of the Order of the Engineer.
Above all, I can point to the Software Engineering Code of Ethics and Professional Practice, which was jointly developed by the ACM and IEEE Computer Society. Even though it's over 20 years old, it has aged extremely well and continues to be a relevant tool for framing ethical discussions. I also find that it's useful to a broad range of people involved in software development - it identifies software engineers as "those who contribute by direct participation or by teaching, to the analysis, specification, design, development, certification, maintenance and testing of software systems" - product managers, business analysts, systems engineers, software engineers, testers, operations, UX designers, and more can all refer to the same document.
When looking at ethics in computing, people are looking at companies like Uber, Volkwagen, Cloudflare and Internet censorship, sexism in the technology fields, the types and amounts of data that is collected on individuals, advances in data analysis and machine learning, and more. This code doesn't address any of these core problems. There is no mention of contributing to society, of honesty, of tolerance and respect for others, respecting privacy, honoring confidentiality, of understanding and applying rules and laws, of presenting risks, of working to improve the public understanding of technology and computing. Most of this oath or code is centered on coding, which, in the grand scheme of all things computing (or even just software) is such a small part.
Also, although I respect his contributions toward the agile methods, software design, and software architectures, Robert Martin is not a good example of a shining light in the are of ethics. Most, if not all, professional codes of ethics will refer to things like respecting diversity, being fair toward colleagues, not discriminating, providing a supportive environment, and upholding these various principles as part of a code. Martin has repeatedly expressed support for individuals who do not uphold these principles of diversity and support (see here, here, and here where he supports James Damore and Doug Crockford). He has also (three times) had to apologize for sexist remarks when speaking and has not demonstrated a true change in behaviors or attitudes. And not just in speaking, but concerns have been raised about the content of two of his books, The Clean Coder and Clean Architecture.
If someone wants to look for a good code, start by turning toward the professional organizations that have put together technologists and ethicists and organized codes that actually set meaningful standards for engineers.
First off, I actually agree with you. This "code" doesn't solve all the problems. If I had a solution to fix all those problems I probably would be doing that. And I don't claim this fixes those issues. Nor do I claim that Martin is a shining example of a good person. But that doesn't mean bad, or people with a questionable backgrounds don't have good ideas. Plenty of good people have bad ideas that get implemented as if it was a revolutionary thing.
My intention with this, is to have a personal code of standards on how you work with the code you write and the effects of how your employer may see your values around such code. The code you write doesn't communicate with other employees around a water cooler.
As for the other links relating to industry standards and how we treat others, thank you. I will check those out for sure. I agree that how we treat others, especially women, minors, and many others is not fair. And that should be fixed. We aren't going to have a one size fits all solution. It also doesn't mean i can't have a personal code of ethics until something does solve them. Not starting somewhere no matter how small is part of the problem.
So with everything you mentioned, I still don't see how this is "awful" based on what you wrote. As those are very much different issues that do need to be addressed. It wasn't intended to solve those.
This is a code that can be used to describe the relationship between a programmer and their code. Just because Martin came up with it doesn't mean that the ideas behind it aren't sound.
This is awful because it's actively harmful. It does not contribute to the advancement of ethics in computing. Instead of producing this, Martin should have been promoting work that includes contributions by people who specialize in society and ethics, such as The Order of the Engineer, the Pledge of the Computer Professional, and the Software Engineering Code of Ethics and Professional Practice. Relating this oath to ethics shows a lack of understanding of ethics in computing and what the real problems and concerns are.
Your post itself mentions the Volkswagen emissions scandal. But consider other ethical dilemmas in computing in the past couple of years - drones and robotics (especially fully autonomous systems and even more especially in the context of warfare), autonomous cars and decision making, the vast amounts of information and how governments and companies are using it (especially aspects of privacy and security), software or systems designed to circumvent the law (similar to Uber's Greyball program), security vulnerabilities (especially in the context of disclosure to the public following incidents), discrimination in the industry. These are the ethical dilemmas that are important to consider and talk about.
We don't need oaths and codes of ethics to tell us how to work with code. We need them to help provide a context for making good decisions in the broader context of complex software systems having a place in society. The "Programmers Oath" won't accomplish any of these things because these problems aren't about code. That's not to say that some aspects of the oath aren't good things to consider. I already picked apart the Oath, and compared it to the Software Engineering Code of Ethics and Professional Practice's ethical guidance..
The fact that this (and not actual ethical codes written with involvement from people who have education and experience in ethics) is endorsed by someone who has great standing in the programming community without promoting other, more robust codes of ethics only leads to the harm. But I have a feeling that Martin won't promote these other codes because he himself doesn't live up to them. I know that I'm not going to be taking advice on ethics from someone who can't conduct themselves in an ethical manner.
You simply have to love uncle Bob! Having these oaths in mind while you are writing software will immensely improve your mental health.
I came across a playlist of Uncle Bob talking about all the oaths not so long ago. Check it out here.
Oh nice. I'll have to check them out. Yea he posts a lot of great stuff. Thanks.