top of page
  • sevcandogramaci

Highlights from the Clean Coder Part 3: Saying Yes

The work environment is different. We are there as a colleague of others and have responsibilities towards our work. Throughout this journey, all of us come across technical and social difficulties in that environment, and learning by experience is challenging. This is where Uncle Bob’s the Clean Coder book comes to benefit us in improving ourselves on how to deal with these challenges and become software professionals.

We discussed Saying No from the Clean Coder in the previous post. Today I will mention the parts that I highlight and apply in Saying Yes chapter of the book.

Saying yes is just as valuable to software professionals as saying no. They are aware that saying yes is taking responsibility and a sign of commitment. Thus, they pay attention to how to make these commitments.

Let’s take a look at what a commitment looks like.

 

We said that a commitment was taking responsibility. While taking this responsibility we should be concise. What does it mean exactly? Let’s investigate it with an example.


I will finish this by Tuesday.

✅ It clearly states the fact that YOU will do with a clear end time. You are stating the action you will take. Neither possibly nor might.

But is this always possible, meaning that can we ensure it all the time when making a commitment?

Not actually.

 

You can only commit to things that you have full control of.

Of course, getting a task done independently of other factors is not always possible. For example, the task may depend on another team’s task. In this case, making a commitment without considering the dependency can cause a wrong estimation.

🔴 It wouldn’t work because I rely on person X to get this done.

If the end goal depends on someone else, software professionals commit to specific actions that bring them closer to the end goal. They meet other teammates, create abstract interfaces and build integration tests.

🔴 It wouldn’t work because I don’t really know if it can be done.

Sometimes the actions to achieve a task can be fuzzy and we don’t know if it is achievable at all. In these circumstances, the professionals can still commit to actions that will bring them closer to the target. For example, finding out if it can be done can be one of the actions to commit to! We can benefit from debugging or working with QAs etc.

🔴 It wouldn’t work because sometimes I just won’t make it.

From time to time, just we may not able to solve a problem. At this time, software professionals raise a red flag as soon as possible to reflect on the problem and not hesitate to get help.

 

In brief,

Software professionals pay attention to what they are committing. They clearly state the fact and take responsibility for their statements. If they notice any obstacles or dependency, they explicitly make others notice them too and they only commit to the actions they have full control of.

That was all for this post, see you in the next post 🧐 🚗

Comments


bottom of page