This is pretty good, but (and this is a common problem, so don't feel bad) you misrepresented the Single Responsibility Principle. What you said about doing too much in one function is correct, but the SRP was actually intended to inform how you create boundaries in your code. In other words, your code should be organized around the structure of your organization.

For instance, let's say you are creating an e-commerce solution. Your company has a sales team, and a delivery team. Both of these teams interact with 'orders' but the requirements of each team is completely different. The sales team creates orders, marks them as paid, and updates their status to 'pending.' Then the delivery team comes along and updates their status to 'processing' attaches shipment information to them etc.

In your org then you have two teams that will come to you and request updates to the functionality. The SRP states that there should be a code based boundary between the verticals that implement this code. This could be expressed in many ways, but it's important to understand the boundary. Now, if the sales team comes and asks for a dramatic change to order processing, the boundary in your application prevents that change from messing up the process of the delivery team, and vice versa.