Skip to Content
Personal Insights

Interview with Robert C. Martin

Dear community, just a few days ago, there was an interview with Robert C. Martin, better known as “Uncle Bob”, published on heise Developer. Unfortunately, only in German. Because I found the interview interesting and the ABAP Clean Code style guide was recently released, here is a small summary of some key topics in English. Have fun while reading ๐Ÿ™‚

The headline could be translated as “Nothing happens in today’s society without software”. Uncle Bob was asked when source code is “Clean Code”. His answer: If the source code was created with care – this means making the source code as understandable, readable and changeable as possible.

For a good reason. The link follows with the topic “Refactoring“: Today we have more source code on which our society depends. Uncle Bob uses some examples to show how people, even their lives, are dependent on software. And today’s software can already be the legacy code of tomorrow. In his guess this will be the case for 80% of the current source code. Therefore refactoring is an important topic.

Afterwards the topic “Test-driven Development” (TDD) was discussed in the interview. The question was how developers make their first steps with test-driven development. His answer: “Very carefully! It’s a skill, not just a set of rules. You have to practice TDD and learn properly before you can work with it seriously.” For this reason he gives the hint to use “safe ways” to practice TDD: Lunch-and-Learn-Events, Coding-Dojos and weekend training.

The next question was whether Clean Code made comments unnecessary. He talked about his rule of using comments: “You write a comment if you are unable to express yourself clearly about the code. You should always try as a first option to write meaningful code. Comments are the last option. In that sense, comments are always a sign of failure and should be seen as such.

And then came a quite interesting question: “Is Clean Code easier or harder to enforce in the open source community than in companies?” He states that the open source community consists of committers and contributors. The contributors develop source code for a project and the committers determine if the source code is ok for the project. In his opinion, this is a powerful control process that should be used by companies. Experienced developers should have the role of the committers. Thus software development standards could be better enforced there too.

The next big part of the interview is about the origins of the “Agile Manifesto“.

Finally, he was asked about recommendations for developers. Here is a summary:

  1. Developers should learn how to write code, write tests, and how to make refactorings.
  2. Developers should learn to read intensively and learn. It’s not just about programming languages, it’s also about the story behind it.
  3. Developers should learn to convey their thoughts and ideas by writing essays, editorials, and blogs.
  4. Developers should learn diligence and recognize what things they should take important. It’s not just the technical quality of their source code, but also the business environment and context.

And here’s one last statement:

Their most important task is to write code that other programmers understand. Many think that the most important thing is that their code is running, but it is more important that other developers can keep their code running.

At this point, my thanks go to the heise Developer Team that published this interview. So you get a glimpse into the thoughts of Uncle Bob and everyone can make his own thoughts.

At the end a few words about this blog: The translation into English was unfortunately not always easy. If I have forgotten important aspects of the interview, please add them in comments. I also tried not to mention my own opinion about the topics of the interview on this blog. This is in my view something for another blog.

 

Best regards and thank your for reading

Michael

 

 

7 Comments
You must be Logged on to comment or reply to a post.
  • Super what a start to monday , speechless after reading this

    You write a comment if you are unable to express yourself clearly about the code.ย You should always try as a first option to write meaningful code.ย Comments are the last option.ย In that sense, comments are always a sign of failure and should be seen as such.โ€œ

    • I also thought a lot about this statement. Apart from that comments are written in the native language or English. Not everyone can read the native language and there are many mistakes when translating into English. And not to forget: the context is right there and can be debugged.Therefore using the programming language is probably more universal.

    • Not sure that I agree with the comment about comments – especially the “always” part of it. I like to add “run-on” comments in the code, mostly of the “why something is happening” sort, but not only. I do this for my own sake to remember what I was up to when writing the code for the time when I look at my own code a while later. Meaningful comments also help colleagues who are not developers but who are able to read and follow ABAP code e.g. during debugging.

  • Nice blog, Michael! I guess you’ve taken his words to heart already. ๐Ÿ™‚ Thanks for making an effort to translate and TLDR the article.

    “Their most important task is to write code that other programmers understand” and the comment stuff – agree wholeheartedly. This actually requires minimum effort and has high ROI.

    There are some items though that I take an issue with, at least when it comes to the ABAP world.

    Experienced developers should have the role of the committers.

    Finding the right “experienced developer” is not always that simple, from my experience. I’ve seen some cases where:

    • the designated person worked for the company the longest but they just have “10 times 1-year experience” since they didn’t learn anything new
    • the person turns into a “gatekeeper” not in a good way (power can get into one’s head quickly)
    • because of their tenure, position or being “teacher’s pet” with the manager, no one dares to question or argue with the “experienced developer”.

    I find that when there is a human being involved it always brings out the related personality issues. That’s why there are some benefits in removing the humans out of the equation whenever possible. Of course we would want to avoid some kind of Terminator style scenario but some routine tasks like code review benefit from automation, in my opinion.

    Coding-Dojos and weekend training.

    Heck no. Why should the developers spend their free time for the job-related training? Is it not enough that we never really leave our job mentally?Training should be done during work hours. That’s exactly the problem: management keeps abusing the developers, don’t give us any time or resources to work on our skills and then complain that we don’t know new stuff. Time to break this vicious cycle, I say.

     

    • I agree with you. The question about the “experienced developer” is really difficult to answer. Maybe it would be good if the developers were allowed to designate this person?

      Sacrificing free time for work is not a good approach. In the end, recovery is lacking and you get sick. In my experience, however, constant training is required. This should be done during working hours.

    • Bear in mind that I am the kind of person who knows enough ABAP to be dangerous (and little enough to be the person who tends to suggests the alternative)

      I work in the font-line of a support organisation; I try to map out a 4 hour block of my weekly calendar for learning (whether it’s reading, writing, practicing …) but this is always disrupted by people (whether it’s manager, co-workers, customers, or god forbid, family..) demanding my time.

      I feel a whole blog coming on, but some thoughts, in no particular order …

      • The experienced Developer / Administrator / problem-solver is the one who gets the most demands on their time.
      • In general, Developers need to think deep and long-term. Managers (whether or not it is deliberate) tend to think short term.
      • Who should you be coding / developing / problem solving for ? the person paying the bills or the end user ? Maybe it it is yourself …

      hth

      • Who should you be coding / developing / problem solving for ?

        This one is simple to answer: everyone, i.e. the developer, the manager, the end user, etc. should actually have a common goal of succeeding together, as an organization. I know some folks would read this and burst out laughing. ๐Ÿ™‚ But that’s what it takes to do things right.

        Managers (whether or not it is deliberate) tend to think short term.

        This is, sadly, true about most middle managers. At the top level, we can still find some strategic thinking. Perhaps the solution is to have the developers report to CIO? ๐Ÿ™‚

        The experienced Developer / Administrator / problem-solver is the one who gets the most demands on their time.

        Yes, and this is usually Catch-22 situation because the experienced ones also need to spend time to maintain their level of expertise. If I find a 100% foolproof solution for this I’ll publish a book, which no doubt will be a bestseller. ๐Ÿ™‚

        So far I found that it’s best to physically remove myself to spend time on learning / thinking. Fortunately, we have a supportive manager who understands that. Although I do end up spending a lot of personal time too.

        Looking forward to your blog, Martin!