The Scribe's Oath
Published: 2022-09-05 02:19:32

## The Scribe's Oath


'Uncle' Bob Martin giving his presentation _The Scribe's Oath_ at the GOTO Amsterdam conference in 2017.

---

Reading and writing was a very specialized skill many moons ago, most people did not need to know how to do either. The scribes of that era, on the other hand, had a literacy most people didn't have. This included writing the laws of that ancient era dictated by the kings, and then reading said laws to determine if they were broken.

---

Because of this particular set of skills ('ello, Liam Neeson), the scribes came to have their own 'special handshakes' and social status.
There was an internal culture with a set of ethics/standards, and an agreement amongst themselves on how to serve their societies as disciplined, orderly professionals.

For example, ancient Egyptian scribes had formatting rules and restrictions (sound familiar?)
When creating copies of the Torah, the scribes had to follow strict rules about the minimum and maximum length of each segment of the scroll, reciting each word out loud as it was written, and cleansing of the pen and themselves before writing the sacred _YHWH_. At the end of each section, there was peer review with specific rules to verify the copy was accurate.

---

Uncle Bob uses this history to draw parallels between those ever important scribes of the ancient past with the programmers that first appeared in the 1940s (Turing vs Ada of Lovelace debates, aside). The growth of the programmer population between then and now, on average, has had a doubling rate of 2.5 years, though Bob mentions this rate was probably much higher at the beginning before slowing to a doubling rate of every 5 years when looking at more recent years.

Either way, the number of programmers in the world doubling every 5 years is significant. This means that half of the programmers in the world have fewer than 5 years of experience, giving a 'state of perpetual inexperience'. Furthermore, the social standing of the programmer has evolved over the decades, from being nearly nonexistent in the 40s and 50s, to being the nerdy, mousey kids in the 70s and 80s, and finally becoming Neo after the turn of the century. From being hardly ever acknowledged to everyone knowing a programmer and living next to one.

Now, as Bob points out in 2015, there was one further step taken after the VW CEO blamed software developers for lying and cheating in their code. As Uncle Bob describes, programmers became the 'highest rank of society: a political scapegoat'.

---

This brings it back to the comparison between the programmers of the modern era and scribes of ancient history. The programmers from VW violated a nonexistent code of ethics by cheating their way to a falsified result. There should be a 'mechanism' to denounce them as programmers and from the programming profession, much like a lawyer or doctor can lose their status as a lawyer or doctor.

Much like the scribes of the past, programmers have a certain literacy with software by being able to read and write the code, while most people cannot (simply because they don't need to know). This is important because it today's world, nothing happens without software. Bob explains how before it was possible to drive a car to the store, even make a telephone call, with no software involved. But no longer because almost everything relies on software to 'control and mediate'.

Like the scribes, the rules are handed to the programmers to write.

---

While society depends a great deal on software, there has yet to be an understanding about how the programmer is the root. Uncle Bob fears it will become known after something catastrophic happens. While there have been terrible consequences due to poorly written software, there still remains the potential for something far worse to happen due to a stupid mistake in the code.

When this happens, the blame (rightfully so) will be placed on programmers and an inquiry will be made. How could something like this happen?

As politicians and lawmakers do, they will pass laws to (in theory) keep this from happening again. To place more control over the industry that caused such an event. Languages, processes, courses etc. all will be outlined in these laws, placing several regulations into place to guide (restrict) how programmers work.

Uncle Bob believes that regulation will come regardless, but worries about government deciding what regulations are enforced. The programmer should be part of these decisions instead of leaving it up to just government to decide. That way, when something terrible does happen, these standards can be referenced. The goal is for programmers to police themselves before their rules get turned into laws, just like many other industries.

---

Uncle Bob's proposal? A programmer's oath (hopefully secret handshakes come into play, too). A list of things that should be promised as a professional. Importantly, he states how 'a professional promise is a promise that exceeds the authority of your employer'. It does not matter what they tell you to do if it violates the oath.

In order to defend and preserve the honor and profession computer programmers, I promise that:

1. I will not produce harmful code.  What does harmful mean?  Every person must make that decision for themselves (i.e. some might consider weapon systems to be harmful, others see them as beneficial).
Programmers can also cause harm if they damage the structure of the code.  If they make the code harder for other programmers to understand and change*.

2. The code that I produce will always be my best work.  I will not knowingly release code that is defective either in behavior or structure.

3. I will provide, with each release, a quick, sure, and repeatable proof that every element of the code works as it's supposed to (i.e. tests).  Code should always be tested.  It is not possible to achieve perfection but it is always an error not to try.

4. I will make frequent, small releases.  I will not impede progress.  Big merges from holding onto the code and not letting others see it will impede associates.  Let others see and integrate your work.

5. I will relentlessly improve the code at every opportunity.  I will never make the code worse.
Bad code slows everyone down.  If you didn't write it, don't allow it to stay.  Don't be afraid, because otherwise the code will rot and get worse since no one wants to clean it.  A trustworthy suite of tests (quick, sure, repeatable proofs) helps alleviate this fear.

6. I will keep productivity (my own and my team's) high.  I will do nothing that decreases that productivity.  I will not damage the code, make it worse, create tests that take hours to run, or check out the code for long periods of time because these would negatively impact that productivity.

7. I will continuously ensure that others can cover for me and that I can cover for them.  Team members cover for each other.  If Bob the database guy gets sick, someone should be able to cover for him.  If no one else can do the database work because he was the only database person, the there is no team.  It is also my responsibility that someone else knows my job so they can cover for me (i.e. pair programming).

8. I will produce estimates that are honest both in magnitude and precision.  I will not make promises without certainty.  'I don't know' is the most honest estimate (though not very useful).  Make it more useful without sacrificing the honesty by outlining and describing the uncertainty.  Making a promise without being certain it can be kept is lying (saying it will get done by Tuesday and not getting it done by Tuesday is a lie).

9. I will never stop learning and improving my craft.  Even though new languages are rehashes of existing solutions, we have to keep on learning because we will have to use those new languages, frameworks, and processes.  This learning should not be done on the job because it is not the employers responsibility to groom my career.  I take responsibility for grooming my career by learning at home, in the evenings, and weekends by reading, playing.  After giving the required 40 hours a week to the employer, all professionals go home and spend a few more.

\*Something he points out is how the 'soft' in software means that it should be easy to change. Software was invented so it would be possible to easily change the behavior of a computer. When the software becomes hard to change, this violates the very reason it was created. Anything a programmer does that makes software hard to change is harmful. Harm is what a software developer does when they release a defect. A defect harms the company that they've written the code for and the users of that code as well.

This presentation is full of wonderful advice and tidbits, so I recommend watching it in its entirety. I believe it is certainly worth several revisits.

{% embed https://www.youtube.com/watch?v=Tng6Fox8EfI %}