Methods really shine when they break large complex pieces of code into small and easy to understand subroutines. This is achievable by calling methods from within methods.

Consider a scenario where several processes must execute when a new employee is created, like updating a human resources system. Our code would need to accept an employee's name and job title to create an employee object and then update the human resources system.

Instead of having this logic in a single method:

public class EmployeeController {

      public void handleNewEmployee(String firstName, String lastName, String jobTitle){
            // Imagine there is apex here that validate the employee parameters 
            Employee newEmployee = new Employee('Elaine', 'Benes', 'Salesforce Developer');        
            /* 
            Imagine complex logic here to update the HR System
            Imagine complex logic here to update the HR System
            Imagine complex logic here to update the HR System
            */
      }
}

We can break up these tasks into 3 smaller methods that each have a specific and well defined responsibility:

public class EmployeeController {

      public void handleNewEmployee(String firstName, String lastName, String jobTitle){
            Employee newEmployee = createNewEmployee(firstName, lastName, jobTitle);
            updateHumanResourcesSystem(newEmployee);
      }

      private Employee createNewEmployee(String firstName, String lastName, String jobTitle) {
            // Imagine there is apex here that validate the employee parameters 
            Employee newEmployee = new Employee('Elaine', 'Benes', 'Salesforce Developer');        
            return newEmployee;
      }

      private void updateHumanResourcesSystem(Employee newEmployee){
            // Imagine complex logic here to update the HR System
      }
}

Now, handleNewEmployee is a driver method accessible to other classes. When called, it delegates the employee creation tasks in an easy to read manner. This method doesn’t know how to create employees or update the HR system, but it knows who does, so it calls them to do it.

Next we’re asked to accept an email address as a parameter in handleNewEmployee() and send the employee an email once the HR system has been updated. Assuming we also updated the Employee’s constructor to accept a 4th argument, the updated code would look like this:

public class EmployeeController {

      public void handleNewEmployee(String firstName, String lastName, String jobTitle, String email){
            Employee newEmployee = createNewEmployee(firstName, lastName, jobTitle, email);
            updateHumanResourcesSystem(newEmployee);
            sendWelcomeEmail(newEmployee.email);
            // sendWelcomeEmail(email); would work too!
      }

      private Employee createNewEmployee(String firstName, String lastName, Integer startYear) {
            // Imagine there is apex here that validates the employee parameters 
            return new Employee('Elaine', 'Benes', 2023);        
            // we don’t technically need to create a variable here. This illustrates how we can just return the object back directly   
      }

      private void updateHumanResourcesSystem(Employee newEmployee){
            // Imagine complex logic here to update the HR System
      }

      private void sendWelcomeEmail(Employee e){
            // Imagine logic here to send an email
      }
}

This type of structure helps make our code more organized and resilient to change. Both the original version and this version work fine, but putting in the effort to create well-defined methods makes our codebase easier to understand and maintain.