That doesn’t seem true to me at all. These, especially, seem like things I’ve tried to stick to that others ignore:
1 & 2 are simple: do no harm, insert no back doors.
5 - Don’t take shortcuts that don’t agree with structure of existing systems.
6 - Team productivity is more important than your personal productivity. It’s fine to just-get-shit-done, but not at the cost of other’s ability to do their work.
8 - Others rely on your estimates. If you’re not sure how something will work, simply don’t make an estimate of how long it’ll take to code it up.
Hmm, it’s the perceived compliance to the rules in the oath that the programmer has no control of. The actual compliance is always measured by a manager/teamlead via KPIs and rules he imposes.
I admit to submitting this primarily because my immediate reaction to it was disbelief and annoyance. That probably means that it’s a good discussion topic, right?
Let’s break it down:
I will not produce harmful code.
“Harmful code” is not always obvious when you write it. If you’re working in a legacy system, you can produce “harmful code” purely by accident.
The code that I produce will always be my best work.
Likewise, impossible. If you’re working on a team with a legacy system, and you have deadlines, you have to do what you have to do in order to get things out: removing side effects and refactoring a vast, sprawling class in decade-old core logic is not usually an option.
I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should…
Er, no you won’t. Tests are not proofs.
I will make frequent, small, releases so that I do not impede the progress of others.
Yes, very important–unless you’re doing a refactor or library upgrade that requires a big-bang release.
I will fearlessly and relentlessly improve the code at every opportunity. I will never make the code worse.
Deadlines again: if you are working against a short deadline, and must deliver a feature, it is definitely possible to make the code worse while meeting business goals.
I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.
Short term or long term? How does this jive with the previous rules?
I will continuously ensure that others can cover for me, and that I can cover for them.
Not really sure how this one pertains to programming: assignments and hiring are not usually in my power, so I can’t control whether there is someone who has the time to learn my organizational knowledge.
I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.
This is impossible. There are entire disciplines of estimation. Vast arrays of books. None of them work.
I will never stop learning and improving my craft.
Finally, something valid! This is the most important and powerful rule, and the only one that is not tangled up in business dependencies or otherwise outside our control as developers.
I admit to submitting this primarily because my immediate reaction to it was disbelief and annoyance.
That is Uncle Bob’s chief export, yes. Frankly I find unpacking his delivery to find the valuable advice carefully hidden within to be net-negative effort for value.
I will make frequent, small, releases so that I do not impede the progress of others.
Yes, very important–unless you’re doing a refactor or library upgrade that requires a big-bang release.
This assumes people are impeded by the frequency of releases. Often times I’m impeded by people releasing often with backwards breaking changes, which make more work for me. I think people should be a lot more thoughtful about releases, rather than just quick about them.
But yeah, I agree with you. This “Oath” is total bullshit. As you point out, a lot of these things are “well, it depends”. If you look at the ASCE Code of Ethics, I think it captures reality much better. It’s about trying to do the best in the situation you are in and acting like a professional.
Engineers shall build their professional reputation on the merit of their services and shall not compete unfairly with others.
Compared to the author’s:
I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.
One is about trying to perform your best and treating those around you well. The author’s is about trying to find some objective way to act. I think the world is too fuzzy for this Programmer’s Oath.
I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should…
Er, no you won’t. Tests are not proofs.
An interesting topic. Unit tests typically prove things about particular inhabitants of a type, but not for all inhabitants.
assert(add(2, 3) == 5)
If this test passes (and add is pure), it proves that add returns 5, given 2 and 3, but it doesn’t prove that add always returns the sum, for all numbers.
Unit tests typically prove things about particular inhabitants of a type, but not for all inhabitants.
It gets even worse. As functions don’t necessarily need to be pure, add(2, 3) might be 5 on the first three calls and something else on the following. Or do some time based calculation, so it only proves that at the time of execution the assertion holds.
Not really sure how this one pertains to programming: assignments and hiring are not usually in my power, so I can’t control whether there is someone who has the time to learn my organizational knowledge.
Coming a bit more from the Sysadmin side of the house, I see no problem with this as a goal. On an ongoing basis you should ensure that what you have basic documentation, and if possible that someone other than you has used each system and has a rough understanding of how it fits.
Perfection is unlikely here, but in my previous job it only took me 20 minutes to handover as almost everything was already either documented or in configuration management.
Completely agree! As a goal, it’s a good one. However, the place where the action can really be taken here is at the organizational level. If your organization has everyone working separately on Deep Magic projects, or doesn’t hire enough good developers to keep the average talent up in the face of attrition, all you can do is document your work and hope someone cares enough to read it.
That’s not how the post is framed, though: it’s “The Programmer’s Oath,” not “The Software Development Firm’s Oath.”
“Harmful code” is not always obvious when you write it. If you’re working in a legacy system, you can produce “harmful code” purely by accident.
Certainly, but by this logic the Hippocratic Oath doesn’t make sense for doctors either, since doctors can do harm accidentally. Professional oaths like these are understood to include an implicit “to the best of my knowledge and abilities.”
The code that I produce will always be my best work.
Likewise, impossible. If you’re working on a team with a legacy system, and you have deadlines, you have to do what you have to do in order to get things out
Depending on the constraints you’re operating under, “getting things out” may actually be your “best work.”
I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should…
Er, no you won’t. Tests are not proofs.
Not in the modern mathematical sense of proofs, but in the more general English usage of “evidence or argument establishing or helping to establish a fact or the truth of a statement,” it certainly is.
I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.
This is impossible. There are entire disciplines of estimation. Vast arrays of books. None of them work.
That has not been my experience. I’ve found estimates produced by a mature team of senior developers to be pretty reliable. But “honest” doesn’t mean perfectly accurate, and if you can’t promise without certainty, then just don’t promise.
You’ll have noted by now that most of my responses have something in common. Namely, you seem to be reading each of these points in the most literal and restrictive way possible. But unlike code, human language typically doesn’t work like that.
“…you seem to be reading each of these points in the most literal and restrictive way possible…”
This is positioned as an Oath. That is, one of the strongest affirmations and most binding contracts that we have. Lying under oath is a crime; breaking a legal contract is not. As such, oaths should be read literally and restrictively. The idea that we should take an oath to take actions over which we have no control is ludicrous–but that’s how the goals are presented.
Then you would of course agree that anyone who has taken the courtroom oath to “tell the truth, the whole truth, and nothing but the truth” is obligated from that day forward to never use hyperbole, tell a story that didn’t actually happen, etc. Because after all, the oath didn’t specify that it applied only to the courtroom, therefore it literally applies at all times. And it didn’t make exception for tales that everyone understands to be fictional, therefore it literally excludes all parables and fictions.
Well established legal oaths don’t stand up to the sort of ultra-literalism that you seem to be proposing.
To be clear, though, I do think Uncle Bob’s proposed oath would benefit from a rewrite. I just don’t think that the reading you’re giving it is a fair one.
Hmm. That is actually the opposite of what I’m saying. My point is that Uncle Bob’s proposed oath (like the courtroom oath) is relatively clear, and can’t be reasonably read in the way suggested above.
Perhaps for some, but I found the Oath as clear as a foggy day. He uses precise language in imprecise ways. Given it’s a programmer’s Oath, “proof” has a pretty precise meaning in programming. But would he consider a demo a proof? Or just tests? Or? I dunno.
He also uses imprecise language in ways where I don’t actually have any idea to determine if I’m abiding by it. What is “harmful code”? Is “Stuxnet” harmful because it purposfully breaks things for the good of some other nation states? Is Uber harmful because it’s putting people out of jobs that lack the ability to retrain in other fields? Should I not work for Uber? A lot of programming is based around putting laborers out of jobs.
I do like the idea of a programmers oath (although I like the idea of a “Code of Ethics” better). Maybe the next revisions will capture programming values a bit better.
I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should…
Er, no you won’t. Tests are not proofs.
He did not mention tests, he was specifically talking about proofs. I was thinking of Isabelle or Coq proofs that the code does what the specification says. Which is certainly time consuming, esp. as then you have shifted the problem a bit to make sure the specification works.
If you read his blog he outright states that tests trump encapsulation. He shows a few examples of how he would rip apart objects to get into them and “test” them. It may very well be that he believes that constitutes “proof” of correctness.
I like the Calling of the Engineer, as recited by Canadian engineering students, as far as these things go.
I, _____ in the presence of these my betters and my equals in my Calling, bind myself upon my Honour and Cold Iron, that, to the best of my knowledge and power, I will not henceforward suffer or pass, or be privy to the passing of, Bad Workmanship or Faulty Material in aught that concerns my works before mankind as an Engineer, or in my dealings with my own Soul before my Maker.
My Time I will not refuse; my Thought I will not grudge; my Care I will not deny toward the honor, use, stability and perfection of any works to which I may be called to set my hand.
My fair Wages for that work I will openly take. My Reputation in my Calling I will honourably guard; but I will in no way go about to compass or wrest judgement or gratification from anyone with whom I may deal. And further, I will early and warily strive my uttermost against professional jealousy or the belittling of my working-colleagues in any field of their labour.
For my assured failures and derelictions, I ask pardon beforehand of my betters and my equals in my Calling here assumbled; praying that in the hour of my temptations, weakness, and weariness, the memory of this my Obligation and of the company before whom it was entered into, may return to me to aid, comfort, and restrain.
Upon Honour and Cold Iron, God helping me, by these things I purpose to abide.
According to this, I’m not a programmer. While I strive not to fail the first bullet point, I often, willingly, and on purpose fail the second. If I didn’t, I’d be out of a job. You see, as a support guy, my job is to fix customer issues fast, in an acceptable way. It will never be the best I can do, because I’m not paid to do that, and the customer wants some fix now, not a week later. Someone else will do a better fix, sometime later. But that’s not going to be me.
I only skimmed the rest of the post, but ended up shrugging it all off as yet another silly rant.
That doesn’t follow. It might exclude you from the category of “professional” programmers by it’s definition, but it doesn’t try to define what “programmers” in general are.
You see, as a support guy, my job is to fix customer issues fast, in an acceptable way. It will never be the best I can do, because I’m not paid to do that, and the customer wants some fix now, not a week later.
So, that doesn’t make sense to me. “Best work” is situational. I’m quite confident that Uncle Bob would be fine with you putting in a hacky fix that keeps the company from losing millions of dollars per hour until someone can replace it with a more rigorous fix. In that sort of situation “hacky fix” and “best work” are identical.
Yet, I also willingly break 5: I often made software worse, intentionally. I broke one functionality, which the customer didn’t use, to fix another. The patch, and to untangle the mess, was left to the developers. They weren’t happy they had to untangle it, which also break another bullet point of the oath.
So, I still believe, that a list like this is completely useless. Because as we just saw, anything, even the most blatant violations of it can be made look acceptable. Just add “under the circumstances” and you’re covered.
if you broke an unused function to fix an important one, you made it better, not worse. But yeah, the list is a terrible collection of pointless platitudes.
| I will produce estimates that are honest both in magnitude and precision.
My estimates will be honest but vague in direct proportion to the vagueness of the story. I can’t say for certain, maybe a day or two, but could be a week. If its more complicated than that, I have no idea.
“Agile” means we have no specs, and the business is free to change the story, which means fine grained estimation is useless.
Furthermore, management might try to turn my estimate into a deadline. Why would I want to enable that behavior? If they can’t provide specs, and can’t provide acceptance criteria, then I can’t provide estimates.
These are neat ideas, but the fact is that most programmers are not professionals, not under the current arrangement.
A profession means that there are ethical obligations that supersede immediate managerial authority. Now, that’s a nice idea, but it requires that the profession ensure the employability (at upper-middle-class or better incomes) of all within it. The AMA limits the number of people who can become doctors, in large part, because it keeps demand for physicians high enough to ensure their ethical independence. Boss fires you because you disobey an unethical order? You’re a doctor; you can get a job anywhere. The dark side of this is that it also requires that the small percentage of people who are bad actors get disbarred (and effectively blacklisted) and one hopes that that power isn’t used politically.
No one has job security anymore, except possibly in the government, but career security is a necessary condition for moral independence.
Programmers can become employer-independent, if they get into the top 1-2%, at least in terms of notoriety (not necessarily programming skill). All of that said, the ones who are obviously out to establish themselves in this set (guilty) are typically likely to face higher-than-average rates of conflict with management and with social expectations.
Maybe this oath was inspired by this article (the article briefly compares the construction industry with the software industry and how roles are viewed and the meaning of the term “engineer” in both of those industries) .
This oath can cause some confusion. Maybe an analogy would help: a construction worker is a subordinate of a construction engineer the same way as a software engineer is the subordinate of a manager/teamlead.
The programmer is at the bottom of the hierarchy just as a construction worker is at the bottom of the hierarchy.
Isn’t subscribing to such an oath something that a manager should do and not a software engineer ?
Also, pretty much every employment document out there would force you to comply to similar requirements as this oath.
So.. it’s a bit confusing why a public oath like that is necessary, maybe just as template?
But.. there’s a confusion even in the title of the oath. What is a programmer ? What is the difference between a software engineer, a programmer and a developer ? I’ve read various answers on the difference between those terms and there wasn’t any consistent definition.
This is an oath about things 99% of programmers have 0 control of.
If this oath is meant to make us all feel bad about the current state of software “engineering”, it does a good job.
That doesn’t seem true to me at all. These, especially, seem like things I’ve tried to stick to that others ignore:
1 & 2 are simple: do no harm, insert no back doors.
5 - Don’t take shortcuts that don’t agree with structure of existing systems.
6 - Team productivity is more important than your personal productivity. It’s fine to just-get-shit-done, but not at the cost of other’s ability to do their work.
8 - Others rely on your estimates. If you’re not sure how something will work, simply don’t make an estimate of how long it’ll take to code it up.
Hmm, it’s the perceived compliance to the rules in the oath that the programmer has no control of. The actual compliance is always measured by a manager/teamlead via KPIs and rules he imposes.
So, uh, no need to write documentation? I’m in.
I’d imagine that falls somewhere in line with the covering for others / allowing others to be able to cover you bit.
I admit to submitting this primarily because my immediate reaction to it was disbelief and annoyance. That probably means that it’s a good discussion topic, right?
Let’s break it down:
“Harmful code” is not always obvious when you write it. If you’re working in a legacy system, you can produce “harmful code” purely by accident.
Likewise, impossible. If you’re working on a team with a legacy system, and you have deadlines, you have to do what you have to do in order to get things out: removing side effects and refactoring a vast, sprawling class in decade-old core logic is not usually an option.
Er, no you won’t. Tests are not proofs.
Yes, very important–unless you’re doing a refactor or library upgrade that requires a big-bang release.
Deadlines again: if you are working against a short deadline, and must deliver a feature, it is definitely possible to make the code worse while meeting business goals.
Short term or long term? How does this jive with the previous rules?
Not really sure how this one pertains to programming: assignments and hiring are not usually in my power, so I can’t control whether there is someone who has the time to learn my organizational knowledge.
This is impossible. There are entire disciplines of estimation. Vast arrays of books. None of them work.
Finally, something valid! This is the most important and powerful rule, and the only one that is not tangled up in business dependencies or otherwise outside our control as developers.
That is Uncle Bob’s chief export, yes. Frankly I find unpacking his delivery to find the valuable advice carefully hidden within to be net-negative effort for value.
This assumes people are impeded by the frequency of releases. Often times I’m impeded by people releasing often with backwards breaking changes, which make more work for me. I think people should be a lot more thoughtful about releases, rather than just quick about them.
But yeah, I agree with you. This “Oath” is total bullshit. As you point out, a lot of these things are “well, it depends”. If you look at the ASCE Code of Ethics, I think it captures reality much better. It’s about trying to do the best in the situation you are in and acting like a professional.
http://www.asce.org/code-of-ethics/
Consider this one:
Compared to the author’s:
One is about trying to perform your best and treating those around you well. The author’s is about trying to find some objective way to act. I think the world is too fuzzy for this Programmer’s Oath.
An interesting topic. Unit tests typically prove things about particular inhabitants of a type, but not for all inhabitants.
If this test passes (and
addis pure), it proves thataddreturns 5, given 2 and 3, but it doesn’t prove thataddalways returns the sum, for all numbers.It gets even worse. As functions don’t necessarily need to be pure,
add(2, 3)might be5on the first three calls and something else on the following. Or do some time based calculation, so it only proves that at the time of execution the assertion holds.Coming a bit more from the Sysadmin side of the house, I see no problem with this as a goal. On an ongoing basis you should ensure that what you have basic documentation, and if possible that someone other than you has used each system and has a rough understanding of how it fits.
Perfection is unlikely here, but in my previous job it only took me 20 minutes to handover as almost everything was already either documented or in configuration management.
Completely agree! As a goal, it’s a good one. However, the place where the action can really be taken here is at the organizational level. If your organization has everyone working separately on Deep Magic projects, or doesn’t hire enough good developers to keep the average talent up in the face of attrition, all you can do is document your work and hope someone cares enough to read it.
That’s not how the post is framed, though: it’s “The Programmer’s Oath,” not “The Software Development Firm’s Oath.”
Certainly, but by this logic the Hippocratic Oath doesn’t make sense for doctors either, since doctors can do harm accidentally. Professional oaths like these are understood to include an implicit “to the best of my knowledge and abilities.”
Depending on the constraints you’re operating under, “getting things out” may actually be your “best work.”
Not in the modern mathematical sense of proofs, but in the more general English usage of “evidence or argument establishing or helping to establish a fact or the truth of a statement,” it certainly is.
That has not been my experience. I’ve found estimates produced by a mature team of senior developers to be pretty reliable. But “honest” doesn’t mean perfectly accurate, and if you can’t promise without certainty, then just don’t promise.
You’ll have noted by now that most of my responses have something in common. Namely, you seem to be reading each of these points in the most literal and restrictive way possible. But unlike code, human language typically doesn’t work like that.
This is positioned as an Oath. That is, one of the strongest affirmations and most binding contracts that we have. Lying under oath is a crime; breaking a legal contract is not. As such, oaths should be read literally and restrictively. The idea that we should take an oath to take actions over which we have no control is ludicrous–but that’s how the goals are presented.
Then you would of course agree that anyone who has taken the courtroom oath to “tell the truth, the whole truth, and nothing but the truth” is obligated from that day forward to never use hyperbole, tell a story that didn’t actually happen, etc. Because after all, the oath didn’t specify that it applied only to the courtroom, therefore it literally applies at all times. And it didn’t make exception for tales that everyone understands to be fictional, therefore it literally excludes all parables and fictions.
Well established legal oaths don’t stand up to the sort of ultra-literalism that you seem to be proposing.
To be clear, though, I do think Uncle Bob’s proposed oath would benefit from a rewrite. I just don’t think that the reading you’re giving it is a fair one.
If you’re going to play the “english is up to interpretation” card, I’m not sure you can tell someone their intepretation is fair or not.
Hmm. That is actually the opposite of what I’m saying. My point is that Uncle Bob’s proposed oath (like the courtroom oath) is relatively clear, and can’t be reasonably read in the way suggested above.
Perhaps for some, but I found the Oath as clear as a foggy day. He uses precise language in imprecise ways. Given it’s a programmer’s Oath, “proof” has a pretty precise meaning in programming. But would he consider a demo a proof? Or just tests? Or? I dunno.
He also uses imprecise language in ways where I don’t actually have any idea to determine if I’m abiding by it. What is “harmful code”? Is “Stuxnet” harmful because it purposfully breaks things for the good of some other nation states? Is Uber harmful because it’s putting people out of jobs that lack the ability to retrain in other fields? Should I not work for Uber? A lot of programming is based around putting laborers out of jobs.
I do like the idea of a programmers oath (although I like the idea of a “Code of Ethics” better). Maybe the next revisions will capture programming values a bit better.
He did not mention tests, he was specifically talking about proofs. I was thinking of Isabelle or Coq proofs that the code does what the specification says. Which is certainly time consuming, esp. as then you have shifted the problem a bit to make sure the specification works.
Uncle Bob is a TDD “guru,” so I feel safe in assuming he means unit tests. I sincerely doubt he means proofs.
I think that’s a warranted assumption, which puts him in contention with Dijkstra’s famous statement that
It’s very odd wording then or maybe he believes tests are proofs?
If you read his blog he outright states that tests trump encapsulation. He shows a few examples of how he would rip apart objects to get into them and “test” them. It may very well be that he believes that constitutes “proof” of correctness.
As a set of goals (with some wishful thinking), it’s not bad. As an oath… well, I’m just glad my doctor hasn’t taken one like that.
That’s the oath of a programmer without deadlines.
In response: http://amcaplan.ninja/blog/2015/11/18/formulating-the-ethics-of-programming/
I like the Calling of the Engineer, as recited by Canadian engineering students, as far as these things go.
According to this, I’m not a programmer. While I strive not to fail the first bullet point, I often, willingly, and on purpose fail the second. If I didn’t, I’d be out of a job. You see, as a support guy, my job is to fix customer issues fast, in an acceptable way. It will never be the best I can do, because I’m not paid to do that, and the customer wants some fix now, not a week later. Someone else will do a better fix, sometime later. But that’s not going to be me.
I only skimmed the rest of the post, but ended up shrugging it all off as yet another silly rant.
That doesn’t follow. It might exclude you from the category of “professional” programmers by it’s definition, but it doesn’t try to define what “programmers” in general are.
So, that doesn’t make sense to me. “Best work” is situational. I’m quite confident that Uncle Bob would be fine with you putting in a hacky fix that keeps the company from losing millions of dollars per hour until someone can replace it with a more rigorous fix. In that sort of situation “hacky fix” and “best work” are identical.
Yet, I also willingly break 5: I often made software worse, intentionally. I broke one functionality, which the customer didn’t use, to fix another. The patch, and to untangle the mess, was left to the developers. They weren’t happy they had to untangle it, which also break another bullet point of the oath.
So, I still believe, that a list like this is completely useless. Because as we just saw, anything, even the most blatant violations of it can be made look acceptable. Just add “under the circumstances” and you’re covered.
if you broke an unused function to fix an important one, you made it better, not worse. But yeah, the list is a terrible collection of pointless platitudes.
| I will produce estimates that are honest both in magnitude and precision.
My estimates will be honest but vague in direct proportion to the vagueness of the story. I can’t say for certain, maybe a day or two, but could be a week. If its more complicated than that, I have no idea.
“Agile” means we have no specs, and the business is free to change the story, which means fine grained estimation is useless.
Furthermore, management might try to turn my estimate into a deadline. Why would I want to enable that behavior? If they can’t provide specs, and can’t provide acceptance criteria, then I can’t provide estimates.
These are neat ideas, but the fact is that most programmers are not professionals, not under the current arrangement.
A profession means that there are ethical obligations that supersede immediate managerial authority. Now, that’s a nice idea, but it requires that the profession ensure the employability (at upper-middle-class or better incomes) of all within it. The AMA limits the number of people who can become doctors, in large part, because it keeps demand for physicians high enough to ensure their ethical independence. Boss fires you because you disobey an unethical order? You’re a doctor; you can get a job anywhere. The dark side of this is that it also requires that the small percentage of people who are bad actors get disbarred (and effectively blacklisted) and one hopes that that power isn’t used politically.
No one has job security anymore, except possibly in the government, but career security is a necessary condition for moral independence.
Programmers can become employer-independent, if they get into the top 1-2%, at least in terms of notoriety (not necessarily programming skill). All of that said, the ones who are obviously out to establish themselves in this set (guilty) are typically likely to face higher-than-average rates of conflict with management and with social expectations.
Maybe this oath was inspired by this article (the article briefly compares the construction industry with the software industry and how roles are viewed and the meaning of the term “engineer” in both of those industries) . This oath can cause some confusion. Maybe an analogy would help: a construction worker is a subordinate of a construction engineer the same way as a software engineer is the subordinate of a manager/teamlead. The programmer is at the bottom of the hierarchy just as a construction worker is at the bottom of the hierarchy. Isn’t subscribing to such an oath something that a manager should do and not a software engineer ?
Also, pretty much every employment document out there would force you to comply to similar requirements as this oath. So.. it’s a bit confusing why a public oath like that is necessary, maybe just as template?
But.. there’s a confusion even in the title of the oath. What is a programmer ? What is the difference between a software engineer, a programmer and a developer ? I’ve read various answers on the difference between those terms and there wasn’t any consistent definition.