Each week I write a blog post which describes what I learned that week. I write these blog posts for two reasons.
First, I want to keep track of my personal development and writing regular blog posts is a great way to do it.
Second, I want to share my findings with you. I hope that you can use some of them in your daily work.
Let’s get started and find out what I learned in week 50.
What I Learned in Week 50
First, Speak the language of your customer.
Two weeks ago I wrote argued that we should name "things" by using domain-specific language. This week I learned that we shouldn't stop there. We should use domain-specific language in our communication as well.
This week my client asked me if it would be possible to change the validation logic of a form X. The form X has a mandatory field called bank account number. My client wanted to make this field optional because it is not required in all use cases.
My first attempt to explain the situation was this:
We cannot make the bank account number field optional in all use cases because it cannot be null or empty in use case X
I thought that I explained the situation pretty clearly but my client didn't understand me. It was time to figure out a better way to explain the situation. I ended up by using this explanation:
The bank account number is required in use case X because you need the payment information so that you can pay to the owner of the bank account.
This did the trick! We ended up making the following changes to the validation:
- The bank account number is still mandatory in use case X.
- The back account number is optional if the use case doesn’t require it.
Lesson: Don't use technical jargon when you are communicating with your customer.
Second, When the shit hits the fan, eliminate all distractions.
When a serious problem is found from a production environment, the events usually follow this sequence:
- I get an email or a phone call, and I find out that there is a problem which requires my attention.
- I start solving the problem.
- After a while I might get a phone call where I have to discuss about the problem and try to figure out what is wrong.
Can you figure out what the problem is?
Exactly.
If I haven’t solved the problem before I get the phone call mentioned in step three, the phone call has two consequences:
- I "lose" my focus and I have to get it back after the phone call ends. This means that I cannot solve the problem as fast as possible.
- Talking in the phone is a waste of time. For example, if my customer has 20 persons who cannot use the system because of the problem and the phone call lasts 15 minutes, my customer will lose 300 minutes of work time (five hours!).
That is why I silence my phone after I have received the first report about the problem and informed my customer that I am solving this problem. This helps me to solve the problem as fast as possible and minimize the damage.
Third, Every improvement counts!
I have been working on the same project for over two years now. During that time I have learned a lot of new things and several new Spring versions have been released (the project is a Spring web application).
The challenge of each long project is to improve the code when you learn new skills and new versions of the used frameworks and libraries are released. Some people argue that for the sake of consistency, the whole code base should use the same way of doing things.
I am not one of them!
I believe that we should rewrite and refactor the code immediately if it looks clumsy or we know that there is a better way to do the same thing. This approach has two major advantages:
- It will keep us motivated. Nothing is more frustrating than following an ancient best practice when we know that is not the best way of doing things.
- It prevents our code base to turn into unmaintainable "legacy code". If we neglect our code base and don't fix its problems when we identify them, our code base will rot faster than we can imagine.
Don't let your code base rot. If you add frequent improvements to your code, the developer who will have to maintain it after you will thank you for it.
Fourth, Choosing a "safe" technology is not always the best thing to do.
Sometimes when we are selecting a technology for a new project, we have two options:
- The "safe" technology. The "safe" technology is very mature and we know it very well.
- The "risky" technology. We have noticed that this technology is getting a lot of traction in blogs and in the developer community in general, but don’t have a lot experience from it.
Enterprise developers often tend to choose the first option, and the hipsters are more likely to select the second one.
I am a bit conservative when it comes to technology selection but lately I have started to question my attitude. I started having doubts when I identified the reasons why I tend to select the "safe" technology. These reasons are:
- I know the "safe" technology very well and I know that it might have a lot of downsides. However, I can get myself around those restrictions, and I know that I don't make mistakes.
- I am afraid that the "risky" technology is not ready for production because I don't know its strengths and weaknesses very well. In other words, I am afraid that I might screw up if I decide to use this technology.
It seems that the main reason why I play it safe is the fear of unknown. Is is really a good reason?
No. It is not!
If we don't have enough experience from a specific technology, we shouldn't abandon it. Instead we should find the answers to our questions and make an educated decision.
Fifth, Nothing beats face-to-face communication.
I have participated to many meetings which were a total waste of my time, and I am not a big fan of "traditional" meetings. However, that doesn’t mean that I would think that face-to-face communication is useless.
I think that face-to-face communication can be a very powerful tool if it is used in the right way. Think about the following situations:
- Pair coding (or debugging) vs. trying to solve your problem alone.
- Doing a quick demo to the product owner who sits next to you vs. deploying the demo to a remote server and asking the product owner to take a look at it.
- Brainstorming with another person vs. trying to get great ideas (or any idea!) on your own.
Do you see the pattern here?
I argue that as long as you avoid organizing a traditional meeting, you can benefit a lot from face-to-face communication.
There has been a lot of buzz about alternative communicate methods such as IM and social media platforms. Although I feel that these are are valuable tools for keeping in touch with my friends and relatives, their biggest downside is that they don't guarantee that the both parties of the discussion are actually paying any attention to it!
That is why I value old fashioned discussion. After all, if the other person isn't paying any attention to it, I will notice that immediately and can act accordingly.
What Did You Learn This Week?
Share your learning experiences or other comments on the comment section.