I am Robert C. Martin (Uncle Bob). Ask me anything.

Held on 24 January 2019, 8:00 pm

Hey there, 👋

Most of you might know me as Robert "Uncle Bob" Martin from Cleancoder.

I am a software professional since 1970. I have spent the last 40 years contributing toward the betterment of the field, from kickstarting the Agile Alliance to authoring landmark books about Agile Programming, Clean Code, and more.

This is your opportunity to ask me anything regarding programming on Hashnode. I will start answering them live from 2 pm CST on 24th January.

Comments (129)

Gonzalo Muñoz's photo

In java programming terms, is static friend or enemy?

James B's photo

What traits do you look for in engineers when hiring them?

Robert Martin's photo

Coding ability is nowhere near enough. Programers need to be good communicators. They need to be articulate, creative, caring, problem solvers. They need to be able to focus deep and long. They also need to be able to talk to business analysts, customers, and managers. They need to be able to see deep details, and also get the big picture. It's a tough mix of attributes to find.

David Intersimone's photo

What do you think about “low code/no code” software-development tools that attempt to allow anyone to create business applications? Microsoft offers their "Power Platform", Salesforce provides "App Cloud/Lightning", Google has "App Maker" and there are many other offerings (Mendix, Appian, Quick Base, Outsystems, etc.). Recent news seems to hint that Amazon Web Services is getting ready to add their offering.

Robert Martin's photo

They make me laugh. It's an old problem. It's been tried many times. It never works quite the way people think it will. In the end, there will always be lots and lots of code.

Take great care that whatever platform you use allows you to write tests. One of the biggest failings of platforms like that is that they don't allow you to test what you write.

Sandeep Panda's photo

What does your daily life look like? How do you spend your free time?

Robert Martin's photo

I am a pilot, and am going for my instrument rating. Learning to fly well take a lot of time. It's also very rewarding.

I write a lot of code. I write books. I write articles, I write scripts for videos. I act in those videos. I review those videos.

I'm pretty busy most of the time.

When I have a free moment, I read, or play Minecraft.

I like watching Youtube videos about flying, or about science. I like PBS SpaceTime, and Veritasium, and Smarter Every Day. I also like conservative political podcasts.

I keep pretty busy.

And if there's nothing else left, I read science fiction.

Sandeep Panda's photo

Robert Martin

And if there's nothing else left, I read science fiction.

What are some of your favorite ones?

Gareth's photo

Hi, what situation(s) have you found where it doesnt make sense to use TDD?

Robert Martin's photo

TDD is difficult to use in situations where you don't know the answer. It's hard to write a test when you don't know what to assert.

So, for example, GUIs. It's hard to write a test for a GUI because you don't really know what you want the screen to look like. Most of the time we fiddle around with the code. We mess with the CSS, and the HTML, we change font sizes, locations, margins, padding, colors, etc. Our eyeballs are the tests.

There are other areas of code that are like that. You don't know what you want the code to do. You have to fiddle with the code until it does something you recognize as "good".

This is a very small percentage of most projects. Most projects have vast suites of highly testable business rules, highly testable formatting rules, highly testable database rules, and a relatively few untestable GUI tweaks.

Carlos Bustamante's photo

Hi Robert Our company will make a 5k marathon clean code running! next month, our tshirt in the back will have this "Best Practices Tips" to recommend.

  1. Apply a design pattern
  2. Follow code conventions
  3. Use meaningful names
  4. Comment your code
  5. Include unit testing
  6. Use Code revision tools

What do yo think about the suggestions!!

Great job with the clean code & architecture book!

Robert Martin's photo

I'd change the shirt to read:

  1. Keep your functions very small.
  2. Extract till you drop.
  3. Make your code read like well written prose.
  4. Care!
  5. Test Driven Development.
  6. Clean before you Comment.
Robert Martin's photo

Good luck with the Marathon.

Matt Madson's photo

Hi Uncle Bob,

How social are your unit tests, If your domain code has a few well defined public api methods but multiple modules that service these public api methods, would you drive all test coverage from the public api methods or test each module independently at their boundaries?

How about mocking and stubbing external calls which make test suites unpredictable. Clearly we should mock and stub, but how should we mock and stub, should we define gateway interfaces to abstract the explicit clients or mock the explicit clients directly. If gateway interfaces, should they be client specific or more generic and use case specific?

Robert Martin's photo

I try not to couple my unit tests to the lowest level code in the system. When I write unit tests using the TDD style, I try to simultaneously create an API that hides the lower level details from the tests.

These APIs are not public, per se. They are relatively low level interfaces used by other modules to access the code that is yet one level deeper. These little APIs keep my tests from becoming fragile.

I try to minimize the number of test doubles and mocks that I use. I mock across architectural boundaries, but within a component I tend not to mock much at all. In particular, I eschew the use of mocking tools. I find it easier, and better, to write my own mocks.

Deactivated User's photo


In regards to your “future of programming” talk. I have been seeking a body or licensure for a “commercial software developers licence”, analogous to a doctor or chartered account licence.

Do you know of any, and what are your thoughts on such a licence?

Do you see a software developers license being significantly different than that of other professions?


Andy Dassing's photo

Is TDD applicable for projects that involve what's loosely termed "R & D" to revamp algorithms for an existing code base with the intent to assess viability for production release?

Robert Martin's photo

Of course. TDD is the discipline of stating what you intend to do, and then doing what you said you intended. This is extremely useful in an R&D environment because those tests may be the only thing that captures your actual intent.

Many people suggest that TDD should not be done in R&D because you don't know where you are going, and you don't know what the answers are.

While that's true at the macro scale, it's not at all true at the micro scale where TDD lives.

For example, say you are building a huge finite element simulator to study the airflow over a new airplane wing. You don't now what this simulator is going to tell you. But you do know the physical rules for air flowing across each finite element. So you can write the tests for those simple physical rules, and you can write them first in the TDD style. And you'd better, too. Because if you make a mistake in writing the code for those physical rules, you'll never know.

Indeed, many scientific papers have had to be recalled because simple bugs were found in the code of their models.

Kaveh Shahbazian's photo

What to do with legacy code?

I have (almost) always have been part of the initiator group of developers of a product. It is the second time that I have to work on some inherited "thing" - some legacy. And I am not making any damn progress in any direction. Where to start? How to dismantle this thing into meaningful pieces? How to make "progress" - assuming it has any meaning in this context?

Robert Martin's photo

This is the hardest thing programmers can do. It's also the thing that most programmers spend their time on.

The trick is to understand that there is no easy solution. It took years to make the mess. It will take years to clean the mess.

So you simply have to begin. Very gradually, and very carefully, clean up the mess.

Do not turn this into a project. Do not tell your boss "We need 3 months to clean this up and then everything will be great". This project will fail, and you will never be trusted again.

Instead, follow the Boy Scout Rule. Every time you check the code in, check it in a bit cleaner than you checked it out. Do some random act of kindness to the code. Don't do too much, because the risk is too high. Just little tiny cleanups at every checking. And never, ever, EVER, check it in dirtier than you checked it out.

If you do this, and if everyone does this, then the code will eventually get better and better. Soon you'll find that parts of the code are decoupled enough to write some tests. The more tests you write the easier it will be to clean the code.

Read Michael Feathers' "Working Effectively with Legacy Code".

Lucas Videla's photo

There are tons of really good books, but we all have a personal favorite. Which one is yours?

Show +1 replies
Lucas Videla's photo

Thanks, Robert! I've that one on my bookshelf, and already read half of it... Need to take it down again!

Corin Lawson's photo

Those video lectures changed the way I think about programming and I soon found Clojure after watching them!

Frigo Coder's photo

Kevlin Henney in his presentation Seven Ineffective Coding Habits of Many Programmers makes an interesting argument at 43:00. He argues that we should write test fixtures that test the entire class for specific example data, instead of writing tests for each method with their own little examples. What are your thoughts about this?

Robert Martin's photo

Kevlin is right about too many things for me to argue with him about this.

Kes Dee's photo

First of all I want to say a big THANK YOU for the impact your books did to my career!

I have several questions for you:

1 - Are you still interested in a new things, and if Yes, what are you studying at the moment? 2 - Could you please recommend some good books, not necessarily about Computer Science? 3 - Could you please tell something about how you conduct job interviews (if you still do that) and what are you looking for in a candidate (apart from tests, clean code, etc).

Robert Martin's photo

1 - Are you still interested in a new things, and if Yes, what are you studying at the moment?

Yes, but there aren't many truly new things nowadays. I like Clojure a lot. I like Event Sourcing structures a lot too. I like functional databases.

2 - Could you please recommend some good books, not necessarily about Computer Science?

You should read the "Bobiverse" trilogy. It's hysterical. goodreads.com/series/192752-bobiverse

3 - Could you please tell something about how you conduct job interviews (if you still do that) and what are you looking for in a candidate (apart from tests, clean code, etc).

I don't interview folks anymore. My favorite technique is to sit down and code with them for an hour or so. One company I know hires people as apprentices, and puts them through a multi-month probationary period during which they must study, write, and produce several challenge projects before they are allowed to work on real systems.

Matt Clarke's photo

Hi Uncle Bob,

Firstly, your clean code videos have been invaluable in helping me become a more professional developer, thank you.

The Agile manifesto and development practices was revolutionary paradigm-shift for the software industry. I was wondering if you've thought about what the next revolutionary change in thinking that will move the industry forward might be like?

Robert Martin's photo

I hope the next revolutionary change never comes. I don't think we need another one. I think what we do need is to complete the gradual adoption of disciplines and professionalism that Agile was a small part of.

Andy Victors's photo

Don't you think the term "dependency inversion" is really far from accurate? There is no real "inversion" in it, the fact that the implementation class is usually drawn under the interface does not justify the name.

Robert Martin's photo

The name comes from the fact that the flow of control and the source code dependency oppose each other. Control flows from the caller to the callee. But the module containing the callee depends backwards towards the called interface.


-----flow of control--------->

Andy Victors's photo

I get the explanation. I'm risking to appear meticulous, but then it is either 'Reverse flow dependency' or 'partial dependency inversion'. Because 'dependency inversion' according to language semantic is about one object which has been inverted. But your description includes two objects - dependency and code flow - and, if we are talking only about dependencies, then only one of 2 dependencies is inverted.

Dean Radcliffe's photo

The Clean Architecture appears to advocate an independence of 'feature laden' frameworks, for the business logic at the center of the circle. Then you look at any framework's tutorials (React comes to mind), and tasks like management of timeouts, and calls out through the boundary layer are demonstrated using the latest features of the framework. If it's Cleaner to not use your UI framework for state management, how come the tutorials are pointing you away from Clean?

Robert Martin's photo

The authors of frameworks are not architects. Their goal is to provide you with useful tools. They generally have no interest in the architectural structure of your system.

Take care. There are very many frameworks that tempt you to couple strongly too them. Often those couplings are so tight that there is no way to undo them. A good architect is careful about this and builds firewalls between business rules and frameworks.

Ismayil Malik's photo

Hi Uncle Bob :)

Will AI eventually replace developers?

I know that you already answered to this quiz in the past but I was wondering do you still think so?

Robert Martin's photo

No. Or at least not until we develop computer systems that have human-like intelligence.

Why? Because of what programmers do, and who programmers are. Programmers are detail managers. We break problems down into the tiniest of little details. Much tinier than our bosses or customers or stakeholders believe is possible or necessary. And each one of those details requires a decision that only a human can make.

Many folks have tried to build system that will make programmers obsolete. One of the first of these was COBOL. The goal of COBOL was to make programming so much like English that customers and stakeholders could write the functional specification, and then just execute it.

That didn't work. The demand for COBOL programmers grew quickly, and so did their salaries.

Since then folks have tried lots of other strategies. One of the latest was MDA (Model Driven Architecture). The idea was that customers, stakeholders, or business analysts could draw high level UML diagrams and execute them.

That didn't work. The amount of detail necessary to adorn those diagrams with required real detail managers to step in. Real detail managers are programmers.

So, no. AI will not replace programmers any times soon. Nor will AIs be driving cars through all our neighborhoods very soon; and for exactly the same reasons. Human judgement is required.

Martin O'Connor's photo

Hi Uncle Bob,

On most of the Clean Coders videos, you invite us into your home and give us the obligatory science lesson before discussing the topic at hand.

Was there a deliberate yet implicit suggestion that this is the kind of lifestyle you can have as a software engineer?

Robert Martin's photo

Nothing deliberate. Nothing implied. What you see is what you get.

I never got a degree. Never went to college. I started as a programmer in 1970 at the age of 18. I worked in COBOL, PL1, FORTRAN, and Assembler. I never looked back.

Now, 48 years later, all those years of experience provide me with the means to make a very comfortable living. But in the early days I lived paycheck to paycheck.

As my experience grew, so did my earnings, but then so did my family obligations. Keeping my head above financial water remained a challenge for over three decades.

I started a business. Employed a lot of people for a time. Don't let anybody tell you that that's a good way to make a lot of money. It doesn't work that way most of the time. Eventually the business failed and left me with very significant debt.

Now, late in life, I can relax a bit. But I don't want to. I love what I do, and I do it really well.

I only hope that all of you can be as happy as I am, and as happy I have been throughout my life as a husband, father, and programmer.

Martin O'Connor's photo

I like this answer. I think the happiness definitely shows through on the clean coders series. I mean look how excited you were with Space War! I want to ask another question about how you keep the excitement alive

Shakhobiddin Urmanov's photo

Hi Uncle Bob, I want to "marry" the Django web framework , is it OK?) What do you think about its architecture?

Robert Martin's photo

I don't know anything about Django. I advise against marrying frameworks though. Try to get the milk without buying the cow.

Javier Exposito G's photo

Hey Robert! Thanks for the AMA and please let me thanks you for your great book Clean Code ;)

I got a question regardless the language eco-system: What do you thinks about learning multiple languages? ... it’s useful or it’s better to stick to one or two languages that could rich practically any kind of software development requirement like web, mobile, desktop like JavaScript?

Thanks again! 😋

Vuk Milićević's photo

Should I install and start introducing myself with HHVM (on my local machine) ?

I am assuming HHVM will stand the test of time and will become available on shared hosting in the (near) future...

M. Bellucci's photo

I’v Never understood what this means. “ depends on things that change less often than you “ Can you give us a concrete example of this advice.

Bogdan Bugarschi's photo

Hi Uncle Bob,

Given that the term Object Orientation is so overloaded and given that you (and a lot of us) use a different, much more rigorous, definition than is generally accepted, do you think it's time to come up with a different name for this?

(UBP instead of OOP maybe :P)

Adam Fraser-Kruck's photo

Hi Bob!

Have you had a chance to try out rust yet? Any thoughts or predictions that you'd like to share?

Thanks for your work. "Come on dogs!"

Spencer Phillip Young's photo

Hi Uncle Bob,

It seems today that everybody and their mothers are adopting "micro-services" or service-oriented architecture. So, I would like to get your opinion on the use of this pattern.

Feel free to give your general thoughts, but I had these questions in mind:

  • For the average org, is SoA successful more often than not and can successes or failures be directly attributed to SoA?
  • Do you see SoA as a lasting trend?

Also, I want to thank you for taking the time to do this AMA! You're an inspiration to us all.

Harsha Jayamanna's photo


I’m working with EJB these days. But I’m mostly interested in Spring, Hibernation and other related stuff. I’m thinking of learning EJB more because it can help me to perform in my job. Do you think learning EJB could help me become a better programmer?

Sky's photo

Hey Robert,

Where do you think coding is moving with AI replacing some of the tasks in the industry? (As in do you think AI would replace basic coding in the workflow?)

Bugra Hasbek's photo

What are your thoughts on writing automated tests for gui?

squid storm's photo

Level 4---- my software Level 3----internal APIs e.g Iaudio Level 2----third party APIs e.g Boost Level 1----language APIs e.g STL Level 0----Operating system APIs

please illustrate for me how I should implement these levels in terms of code ?

Martin Moreno's photo

Hey Bob!

About the Clean Architecture, Use Cases in particular, do you think they map 1:1 to the concept of Action proposed by Mancuso in Interaction Driven Design? If not, what differences do you find?