Uncle Bob is very famous for his ideas on Clean Code. He is very hardliner on Test driven development.
I am big follower of him and have read few books Clean Code , Clean Coder written by him, i have become better programmer after reading his books.
I read Clean Coder few years back and felt that this book is must read for every professional software developer.
Uncle bob recently gave a talk The Scribe's Oath , that summaries the whole book in 1 hour.
In this talk he sets nice context before getting to real stuff. He talks about couple of Oaths for programmer.
Not writing harmful code
He talks about harm software developer does by releasing defect , makes code harder for other programmer to understand. Software should be easy to change and anything that makes hard to change is harmful code.
Code that i will produce will be my best work
This is something that you are proud of.
Each release with quick , sure & repeatable proof that every element of code works as it is supposed to.
This is all the TDD, BDD, CI etc thing comes in. It is inappropriate to accept some level of defect.
Frequent small release and not impede progress
Holding code to yourself and not let anybody seeing it, holding on to big commit are few things that will impede progress. Small releases are better.
Fearlessly and relentlessly improve the code at every opportunity and never make it worse.
Almost every software developer is slowed down by bad code , but we still continue to write bad code for some reason. We allow bad code to rot in absence of automated Unit test. This is where The Boy Scout Rule is useful . Automated test are really useful to keep this promise.
Keep my and my team productivity high.
Don't hold on the big commit, don't create test that takes hours to run.
Continuously ensure that others cover for me and i cover for them.
This one is interesting, he talks about working like sports team and handling situation when one of the team member is injured or down.
Pair Programming can be good tool to achieve this.
Produce estimate that are honest both in magnitude and precision, no promise without certainty
This is tricky one, most honest estimate is "I DON'T KNOW" but this does not work in real world and we fall in estimate trap and make false promise. He recommend to draw curve around uncertainty.
You manager will come to you and say that we need this in next 2 days , can you try ?
Your answer to this should be i am already trying and not holding back any extra capacity. You should say no, when it is not possible .
Never stop learning and improving my craft.
You have to keep on leaning new language, framework, library otherwise you will fall behind and have to become manager :-)
Links to some of Uncle bob talks that i found good
Effective Estimation (or: How not to Lie)
The Principles of Clean Architecture
What is OO really
SOLID Principles of Object Oriented and Agile Design
I am big follower of him and have read few books Clean Code , Clean Coder written by him, i have become better programmer after reading his books.
I read Clean Coder few years back and felt that this book is must read for every professional software developer.
Uncle bob recently gave a talk The Scribe's Oath , that summaries the whole book in 1 hour.
In this talk he sets nice context before getting to real stuff. He talks about couple of Oaths for programmer.
Not writing harmful code
He talks about harm software developer does by releasing defect , makes code harder for other programmer to understand. Software should be easy to change and anything that makes hard to change is harmful code.
Code that i will produce will be my best work
This is something that you are proud of.
Each release with quick , sure & repeatable proof that every element of code works as it is supposed to.
This is all the TDD, BDD, CI etc thing comes in. It is inappropriate to accept some level of defect.
Frequent small release and not impede progress
Holding code to yourself and not let anybody seeing it, holding on to big commit are few things that will impede progress. Small releases are better.
Fearlessly and relentlessly improve the code at every opportunity and never make it worse.
Almost every software developer is slowed down by bad code , but we still continue to write bad code for some reason. We allow bad code to rot in absence of automated Unit test. This is where The Boy Scout Rule is useful . Automated test are really useful to keep this promise.
Keep my and my team productivity high.
Don't hold on the big commit, don't create test that takes hours to run.
Continuously ensure that others cover for me and i cover for them.
This one is interesting, he talks about working like sports team and handling situation when one of the team member is injured or down.
Pair Programming can be good tool to achieve this.
Produce estimate that are honest both in magnitude and precision, no promise without certainty
This is tricky one, most honest estimate is "I DON'T KNOW" but this does not work in real world and we fall in estimate trap and make false promise. He recommend to draw curve around uncertainty.
You manager will come to you and say that we need this in next 2 days , can you try ?
Your answer to this should be i am already trying and not holding back any extra capacity. You should say no, when it is not possible .
Never stop learning and improving my craft.
You have to keep on leaning new language, framework, library otherwise you will fall behind and have to become manager :-)
Links to some of Uncle bob talks that i found good
Effective Estimation (or: How not to Lie)
The Principles of Clean Architecture
What is OO really
SOLID Principles of Object Oriented and Agile Design
