As a leader I decided to take for a spin such technologies before fully embracing them or even asking my teams to play with them. And the lines below summarize my personal journey and my 2 cents on the matter:
On average, developers produce or change 30 lines of code a day. Most of that time is spent on reading and trying to understand code so they can change it.
It’s almost a 10:1 ratio of reading versus writing code.
If I knew a DB table was going to be read 10x more often than writing to it, I wouldn’t optimize it for write speed.
That’s why Kent Beck’s Simple Design prioritizes:
- Passes the tests
- Reveals intention (should be easy to understand)
- No duplication (DRY)
- Fewest elements (remove anything that doesn’t serve the three previous rules)
There are wording variations on those rules, but I got those specific words from this Martin Fowler post. As he notes, “The rules are in priority order, so passes the tests takes priority over reveals intention”.
Developers who are disciplined will spend at least half their time refactoring the code to satisfy 2–4 as best as they can. We spend a lot of the remaining “coding” time writing tests.
I have experimented doing Test-Driven and Test-After development with GitHub Copilot and GPT-4, and they just got in the way.
Mentoring developers vs Coding, I realised that it’s better to turn Copilot off. It was just noise!
