Craftspersons oath - Robert Martin presentation 2018

I'm a fanboy of "Uncle" Bob Martin. An original signer of the Agile Manifesto. Author of Clean Code book and other "Clean" books. Frequent presenter. Yes, he has a certain style which does not appeal to everyone (I dig it). Yes, some of the content is showing its age with tech changes over last 10+ years. But Bobs also created some timeless content.

I enjoyed watching Bobs video presentation on the Craftsmans oath (2018) recently (but let's change to Craftsperson ok?) and below are my notes on what Bob said. The tldr in my words:

A craftsperson is someone who stands for something and cares about doing things "the right way". They care about the code, their teammates and customers. They produce quality code, write tests, don't settle for the first solution but refactor code regularly to improve it, deploy small frequent releases, pair with others, are good teammates and collaborators, are learners and teachers both, and don't bs themselves, their colleagues, the customer/product/manager.

And before we jump in, an interesting counterpoint from Dan A. about clean code and his learning

To start, Bob asked:

Are you proud of what you did? of the way you work?

• discipline, orderliness, self respect

You earn trust by the quality of your work

• your customers trust you, your manager trusts you, your peers trust you.

Craftsmanship is a set of promises you make yourself, a "code" you adhere to. Craftsmanship is part of agile, it includes

• whole team, collective planning, small releases, acceptance tests
• continuous integration, collective ownership, sustainable pace
• simple design, pairing, refactoring, test driven development 

As a craftsman, Bob has a set of promises to himself & teammates.

"I will not produce harmful code"

• harmful? to society? to data? to other people who maintain the code? to customers?
• software is ubiquitous: phone, cars, plans, trains, cash register, hospitals.
• how many people have died due to software errors?
• talked about the case of software devs in VW who wrote code to cheat emissions, got blamed and went to jail
• software came about because of the need to be able to change machines (hence the "soft" versus hardware which is not easily changed)

"the code I produce will always be my best work" (I can do) "and I will not knowingly allow code that is defective in behavior or structure to accumulate"

• means I will be going over the code, improving it, refactoring
• how can I make it better? 
• "clean code" is when it pretty much does what you expected

"I will produce with each release a quick, sure and repeatable proof that every element of the code works as it should"

• our users expect the code works, the code in phones, cars, air traffic code, restaurant systems etc works
• tests are softwares equivalence to an accountants double entry, a way of checking our work

"I will make frequent small releases so I don't impeded the progress of others"

• checkin daily or more often and tested in CI

"I will fearlessly and relentlessly improve our work at every opportunity"  "I will never allow it to degrade"  

• fear: if I touch it then I break is and own it...then its guaranteed to entropy
• how to stop the rot?
• A. get rid of the fear
• how?
• with tests

"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"

• if you write tests later the risk is you're not really building good test coverage
• a good test suite is you are confident to make a decision to 
• ship it
• refactor it

"I will continuously ensure that others can cover for me and I can cover for them"

• how should a team work? if someone goes down then the team covers for each other
• how do we ensure that coverage?
• A. pair programming   

  

"I will produce estimates that are honest both in magnitude and precision" "I will not make promises without certainty"

• who's good at estimating? most of us are not
• yes we do have estimates in Agile
• the most honest thing you can give: best, realistic and worst case estimates
• when pushed don't lie, don't say "yah, ok I'll try"

"I will never stop learning and improving my craft"

1. the best way to learn is to teach
2. universities don't necessarily teach what you actually need in day to day work, you learn from peers and others

Bob asked "why is tdd not adopted more, not more prevalent?"

• Is's a good question. I personally practice tdd less than 3rd of my time. I pair program but only a few times a week and that is also dependent on my colleagues willingness. 
• Some reasons: 
• engs don't understand the value of tdd
• deadline pressures
• it can be a lot of extra code, if refactor then have to rewrite tests
• the unit tests may not be the right tests, Kent Beck said "test as little as possible to reach a given level of confidence". Write tests for code with complex logic, not for mistakes your rarely make. Write tests for code that's risky (of failure).
• Code coverage. True value is to help find important gaps, not so much as a % score.