Uncle Bob Martin

Uncle Bob Martin


Software Craftsman

151259 followers  •  308 follow  •    •   http://t.co/cEFTI5CDhO

In 1964, for my twelfth birthday, my mother bought me this little plastic computer. Three flip-flops and six and gates programmed by slipping little white tubes on the pegs of those flip-flops. My passion was ignited, and the course of my future was set.

tweet picture

In the last years of the ‘60s my good friend, Tim Conrad, and I tinkered together these electronic contraptions. Power supplies, timing devices, pulse generators, and a binary, 18 bit, four function calculator of our own design.

tweet picture

Have you seen the free videos on the youtube channel? Some classics.

Have you learned how to fly an airplane? You really should. You’ll learn a lot about the value of discipline.

Fails on ones-compliment machines that allow both values of zero. <grin>.

I never got a degree. I just read like a banshee and taught myself to code. I think I did OK. ;-)

Loading
Loading

Never ask permission to refactor. Never ask permission to write tests. You do these things because you KNOW they are the best way to go fast. When you ask permission, you are asking someone else to take responsibility for your actions.

The word “refactoring” should never appear in a schedule. Refactoring is not a story or a backlog item. Refactoring is not a scheduled task. Refactoring is immediate and continuous. It’s like washing your hands in the bathroom. You always do it.

Agile is not a way to go fast. It is a way to know where you are going. Agile is does not increase productivity. Agile increases manageability. Agile does not guarantee you’ll get there on time. Agile destroys the hope that you might, when you won’t.

It is more important for code to be changeable than that it work. Code that does not work, but that is easy to change, can be made to work with minimum effort. Code that works but that is hard to change will soon not work and be hard to get working again.

Most programmers want to write good code; but believe that their employers don’t want good code. They are wrong. Most employers want the benefits of good code; but don’t know that good code provides those benefits. We do. So, we should write good code.

There is no trade-off of quality vs. speed in software. There never has been. Low quality means low speed. Always. The only way to go fast is to go well.

Developers do not have to justify testing and refactoring to management; because those disciplines increase efficiency and productivity. Indeed, it is the lack of such disciplines that ought to require justification. I doubt any could truly be found.

Quality is the key to speed. You go fastest when you go well. And never ask for permission to go well; that’s your responsibility and no one else’s.

Writing code is one of the most difficult of human endeavors. No one has mastered it. After seven decades we are still trying to work out the basics.

Software Craftsmanship is not about glory and rockstar status. It’s not about being the overtime hero, or the last minute cowboy. Rather it is about discipline, professionalism, and the desire to constantly improve.

Loading
Loading