Clean code training at generic.de: an interview with our clean development trainers

‍Learning Clean Code Development requires a lot of know-how, practice and experience. For over 12 years, we have committed ourselves to developing cleanly and firmly anchoring clean code development in our corporate principles and projects. Our Clean Development Trainers are now sharing this knowledge and their practical experience in internal and external training courses. How do the training courses run and what learning content is taught? We asked our trainers Felix and Thomas.

‍

Why are Clean Code training courses booked with you?

Felix: I dare to say that everyone who writes software and every company that has any software department runs into the same problem sooner or later: The source code is no longer expandable and implementing new features costs an incredible amount of money. If you deal with the problem behind it, you quickly come to the topic of clean code. And there is also an insane amount of material about that. However, the topic also quickly becomes apparent because it is so extensive. Talking to colleagues who have already had experience with this is therefore very helpful for many. And it is precisely this experience that we share in our training courses. Because we know the problems, we also experience them every day — and have suggestions for solutions to deal with them.

Thomas: The companies that request training from us are in very different places. It is partly about knowledge about the technologies, partly about the clean code concepts. We therefore talk to the participants beforehand to find out what the pain points are. For example, the topic of automated testing: Participants often know that tests are extremely important in software development. And they also want to test — but they simply don't know exactly how to tackle such a big topic.

“For us, it turned out that the right mindset is almost as important as craftsmanship. ”
(Thomas)

‍

What are your learning goals with the training courses?

Felix: First, it is important for us to become aware of the problem: What happens if we don't develop according to good craftsmanship? This goes hand in hand with the issue of software quality: external quality, which you just see when you use the application, but also internal quality that only software developers see.

Once this awareness has been created, it is about craftsmanship. So which principles and practices from the Clean Code books can you apply? Which are important, which are less important? Another major part of our training courses revolves around the question: How do I actually get from requirement to code? How can I break down problems that the customer poses to me — we also speak of cutting — so that they can be meaningfully represented with source code? Because if I work correctly and thoughtfully during this design phase, I will generate clean or rather extensible code later on almost automatically.

Thomas: Another learning objective of our training courses is the topic of mindset. For us, it turned out that this is almost as important as craftsmanship. In other words, how you work together as a team, how agile or not you work, how focused you are on completing increments. As an example: No code that we write goes into production without a review. That means at least two or three other developers must have looked at the code. One practice that we recommend time and time again is joint code review with the entire team. Because you can also learn a lot and continuously develop yourself when communicating via code — in a project, in a team and in the company.

‍

How does Clean Code training work in detail?

Thomas: At the beginning, we always give an introduction to Clean Code and the Clean Code Initiative. That's when a big block revolves around automated testing. And the third big block is about flow design, where we talk about how to break down the requirement, how to design the software and how to implement it.

Theoretical parts and practical parts alternate again and again. The participants do exercises on a specific point that they have previously dealt with theoretically. And then in the review, you look at what has been implemented well, where there are still gaps and then deduce what you need to go into more detail in the next part of the theory.

Felix: In other words, we are able to dive into various topics at different levels. This is also partly due to the dynamism of the group. This whole mindset topic, for example, is not necessarily something where you say: Okay, now let's do a quick mindset and then the topic is over. Instead, this is of course something that we come back to again and again — for example during practical exercises.

“The best way to learn is simply to participate. ”
(Felix)

‍

How are the theoretical and practical parts distributed?

Thomas: Rather more practice. A big practical part is code review — i.e. discussing the created code together. The participants always learn a lot because they are simply practical examples and source code created by themselves.

Felix: Getting started is, of course, more theory-based. But we are already making sure that we present everything that we teach in theory in practice through exercises, examples or demonstrations, in order to interactively pick people up in the theoretical parts as well. Participating is what you learn best about.

‍

How can you imagine such exercises?

Thomas: Programming hangmen, for example. So write a small class, a console program or — when it comes to testing — a function with which you could implement the children's game Hangman. Or even something more complicated: During our last training session, for example, we completed a questionnaire.

Felix: We have a good pool of exercises that also address various topics. We then select them specifically in order to deepen a topic that we have addressed or discussed theoretically through practice.

‍

What does a code review look like in your training courses?

Felix: The code that person A wrote in the hangman practice task, for example, should be reviewed by the team. To do this, another person B must present their foreign code to the team. With Clean Code, readability is always a big issue. And through this process, we ensure that someone else can read and explain this newly created code correctly without having to go deep into it. However, the authors are also there so that inquiries can be responded to quickly. Comments are then created and these comments can be edited in parallel by the entire team. This puts you very much focus on completing and finishing things.

‍

You mentioned Flow Design earlier. What is that exactly?

Felix: An application is there to solve problems. And these problems that are out there with our customers in the world, we first have to map them with code. Flow Design is a technique for cutting these problems into many small pieces, which can finally be mapped with source code.

Thomas: It is important to us that we think about how we write the productive code and how we disassemble it before the first line of code. And that is exactly the part that we understand by flow design. With Flow Design, we can break down customer requirements in such a way that we get ever deeper and have ever smaller components. For them, we can then clearly define how they should work in the code. This is incredibly helpful for readability and traceability in code. And it also allows me to properly approach and plan the topic of testing right from the start.

“We're talking about Test First. This means that before I write a line of production code, I have to think about how I could test this function. ”
(Felix)

‍

Speaking of automated testing: Why is the topic so important and how do you teach it in training courses?

Thomas: If I've broken down the customer problem into small pieces using Flow Design, then there might be some mathematical calculations or logics at the deepest level. I need to be sure that they work. Through automated tests in the form of separate code that is next to the production code, we can ensure that the code also does what it should do. One of the biggest problems with projects that are no longer maintainable is that you no longer trust the code. If I make a change somewhere now, I can't be sure if everything is still working. And always testing this manually would be extremely difficult and time-consuming.

Felix: We're talking about Test First. This means that before I write a line of production code, I have to think about how I could test this function. Test cases are also a great way to ask customers what they actually imagine. Let's take the hangman example again. You could then ask: “If I now enter the same letter twice in a row, what should happen then? “The customer can choose that. This means that we also train our participants to ask such questions. In addition, tests freeze the current status of functional requirements — even for developers who will continue working on them later.

However, testing is a real craft that you have to learn. That is certainly a hurdle for now. And it's actually better to take them when someone is there who can help you get going if you don't get the first test done. However, as soon as you have internalized the concepts and know which technologies are available, that is no longer a problem. If I know how to write a test, then I don't have to worry about how anymore. Then it's more about which tests are important to cover my application in a meaningful way.

‍

Clean code development is not just tips and tricks, but a complete system of values. How exactly can you imagine that?

Thomas: One of the key topics of the Clean Code Initiative is the four values: The correctness. In other words, that the code does what the customer wants. The expandability. This means that functionalities can still be added to the code even after 2, 3, 4, 5, 10 years without having to rebuild it for months. Production efficiency. That the team can also incorporate new features with a certain speed and efficiency. And continuous improvement. Continuously improve, reflect and also question yourself and as a team.

Felix: The ultimate goal must be to live up to these values. It is not always necessary to completely fulfill all principles down to the smallest detail. Because these over 40 principles all only contribute to the values. If I violate one or the other principle but still efficiently produce correct and developable code, that's completely okay. Developing such a pragmatic way of thinking is very important.

“Making optimizations now for a possible future that you have no idea whether they will work only adds unnecessary complexity in almost all cases. ”
(Thomas)

‍

Is there such a thing as the best of the clean code principles?

Thomas: Depending on the project and code structure, different principles are of course important. Still, there are evergreens that you should always follow. For example, the “Single Responsibility Principle”: A method or class should only ever have one function. If a method has five different functions, then it is difficult to test them because you would then have to write tests for all five things, maybe even for all possible combinations. However, if you split it into five methods, then the individual methods can be tested separately.

Felix: “Don't Repeat Yourself” is another of the central principles — the copy-paste problem. If you find that there are duplicates in the code, you do the same thing over and over again in different places. Because this necessarily means that you make some changes in one place but forget the other three places. They then work according to the old principle and are prone to errors. So they fixed a bug, but only in one place. This also makes it unnecessarily complex to understand how the code works.

Thomas: Then — more in terms of working methods — “You Aint Gonna Need It.” It's about saying: “Let's omit that part for now.” Tailoring participants to the YAGNI principle is a huge part of the training. Focus on what you need right now and don't try to solve problems now that could potentially arise at some point. “Beware of Premature Optimization” hits a similar score. This is based on the thinking: “Oh, I'm optimizing this directly for performance because I'm potentially going to have 5 million users.” But the fact is, especially at the beginning, that you might have 50 users. Then you can't let the customer convince you that it must already be highly scalable. Making optimizations now for a possible future that you have no idea whether they will work only adds unnecessary complexity in almost all cases.

Felix: In addition, the “Integration Operation Segregation Principle.” It is important that we cut our application into functional units that are called up as if in a chain. This means that, for example, in a top-level accounting application, I define: “We want to add a transaction.” And then we ask ourselves what that actually means. This may mean saving the booking in the database first and then adding it up. And so we go deeper and deeper into this decomposition and thus obtain an application that is driven by data flows.

‍

Do you also offer code checks?

Felix: Code checks are actually a very good way to find out where a company stands with its code base. We can see relatively quickly whether there are violations of clean code principles and can discuss them together. We can also immediately give tips on how to write the code differently in this or that place and what advantages result from this. In the end, the truth is always in the code.

Thomas: We approach code checks in a very similar way to code reviews. If I can get an overview relatively easily, flow design was probably used. That's when I see the top level and can zoom in bit by bit. If that is not the case, the code already has a certain flaw. Readability is one of the greatest assets. Because if I can't read and understand the code correctly, I can't add functionalities to it.

I find it interesting that people often think: “Oh my, I'm too stupid — I don't understand this code.” But no, it's not because of me, it's the code. And when you ask the original developers to explain the code, they usually notice for themselves that they wrote something confused or formulated it unclearly. This often unties the knot to find out what you actually need to change.

‍

Who are the Clean Code training courses for?

Felix: It must be people who develop software. Otherwise, it doesn't make much sense. Although we also give talks about the benefits of clean code at management level, the training courses simply require a certain amount of previous knowledge in software development. This can be very different, but here too, it makes sense to bring together developers with similar levels of knowledge. People who have been developing for many years and are very fit in unit tests, for example, are of course quickly bored when there is the third test exercise. In this respect, it would be good if it was a homogeneous group as far as previous knowledge is concerned if possible.

‍

Thank you very much

‍

Would you like to receive more information about our Clean Code training courses? Or request training for your team right away?