Articles from February 2017

Developers Give “If Condition” a Name

Hey, you have been writing software for 10+ years. Can you give me advice, tips to improve my skills?

What if someone asks me that question?

I can go on and on with many things. And finally, they will be confused and lost. What if I have to give only one advice?

I will say

Improve your naming

I once wrote the naming matters. Today, I give another small tip on naming

Give your “if condition” a name

Let take a very simple code

public int CalculateFee(Customer customer)
{
    if (DateTime.Now.Subtract(customer.RegisterAt) > TimeSpan.FromDays(30))
    {
        return 100;
    }
    return 200;
}

The condition is, “If a customer has registered for more than 30 days, charge 100 (assume it is USD). Otherwise, it costs 200.”

What is the big problem with that code? The problem arises when other developers read the code. He does not speak the same language as when you wrote it. He will, mostly, read the code with the C# language syntax and try to figure out the logic.

An “if condition” is a business logic. Therefore, it should be named properly.

Now, let refactor code and give it a name.

        public int CalculateFee(Customer customer)
        {
            if (CustomerRegisteredFor30Days(customer))
            {
                return 100;
            }
            return 200;
        }

        private static bool CustomerRegisteredFor30Days(Customer customer)
        {
            return DateTime.Now.Subtract(customer.RegisterAt) > TimeSpan.FromDays(30);
        }

Think about multiple operators condition. You will see a big benefit.

 

There is a huge number of conditions in every codebase. If you write a new “if condition” or you see them in your current codebase, give them a favor

An “if” is a business logic, give it a name. If you cannot name it, you do not understand it.

Other developers will thank you for that.

A small action but big impact.

Developers How To Be More Valuable

Developers love challenges, technologies, cool stuff. They are very creative. I heard people ask

  1. How to become a better developer?
  2. What technologies should I learn?
  3. What languages should I learn?
  4. ….

The questions go on and on. But, Yes. Always there is a “but”.

Are they the right questions to ask?

Everything only makes sense in its own context. So the post: Developers who are hired by companies to develop business software.

Broken Light Story

Mary has a broken light in her house. She calls a John come to fix the light. John fixes the broken light quickly. The job is done. He gets paid. However, Mary is not really satisfied. Because, John, while fixing the light, dropped dust on the floor. Mary has to clean it up.

Oops, again, the another light is broke. However, this time, she decides to try to reach Steve. Steve comes and fixes the light. Before claiming the job done, Steve cleans up the floor, he also does some check up on the other lights in Mary’s house. It costs Mary the same price as using John’s service.

Can you guess who will get more clients? Of course, that is Steve. Steve is more valuable than John.

So, what is the difference?

The same task, different delivery quality.

Oh! A nice story! But I am a developer. What is in it for me?

Yes. My friends, we can apply the same philosophy to increase our value. Remember this?

You get paid for the value you bring to the marketplace.

Our value is determined by

The quality of our deliveries define our value, not the tasks.

Developers’ Clients

Have you ever thought of who are developer’s clients? What? Do they have clients?

Yes. Yes. And Yes. There are.

Whoever use their deliveries are their clients.

QA/Tester

At daily basis, developers implement user stories, fix bugs. QA/Tester will verify their deliveries.

Code Reviewer

Given that a company has a code review process. Code reviewer is developer direct client.

Leader/Manager

Of course, they are your clients.

Other Developers

You are not alone in a project. Some other developers will use your code. They consume your API.

There might be more clients. You get the point.

A Better Question

What should I do to increase my value to my colleagues, my company?

Some might think of solving challenging tasks, implementing cool stuff. Yes. They are true. However, there are not so many challenging tasks in a company. Let’s take the “80/20” rule. There are 20% of challenging tasks.

You have to find ways to take advantages of 80% left to increase your value.

Increase Your Value

Here are some tips that can help you, developers, increase your value.

Comment Your Deliveries

These days we all use tools (Jira, Targetprocess, Trello, …) to manage projects. Your tasks are presented as Cards (User Story Card, Bug Card, Task Card). Each card has a powerful feature for communication: Comment.

You should take advantages of the comment feature.

User Story/Task

Usually, you should write

  1. Question: To communicate with the card owner or other developers in the team. There is another skill you need to learn here: How to write a good question?
  2. Technical Design: Write whatever you think they are valuable.
  3. Solution: So other can know what you have done to finish the job.

Bug

Usually, you should write

  1. Question: To clarify the bug.
  2. Done result: This is a crucial part. When you fix a bug, you should write in detail

How to write a “bug fixed” comment? There are at least 3 parts.

  1. Root Cause: What is the root cause of the bug.
  2. Solution: How you solve the problem. The more detail the better.
  3. Test result: Prove that you have tested your fix.

Think Before Code

I am serious. Here is what had happened to me many times.

  1. I got a bug to fix.
  2. I located the place that bug occurred.
  3. I added my code to the existing code.
  4. Compiled and tested just my scenario.
  5. QA claimed my bug passed. And congratulated me that there was a new bug. Guess what? Most of the time, it was me creating a regression bug.

The dangerous thing is fixing a small bug causes a critical bug.

Ask these questions before code

  1. How can I fix the bug without modifying existing code?
  2. If I have to modify, what are side effects? How many affected places I can think of?
  3. Do I understand the logic of the code I touch? At least at the method level, you should understand its logic.

Lesson Learned

You cannot grow if you cannot learn anything after each task. There is no silver bullet for learning. Each must find their own way. What you can do is to set your mindset.

After each task, you can ask yourself this question:

Hey! What do I learn from completing this task?

And you must be serious.

 

In conclusion, with the context of a company, being a software developer looking for ways to increase income (oh yeah cash, money), you should ask a better question.

As a software developer for 10+ years, I would like to offer you a new question

What should I do to increase my value to my colleagues, my company?

And 3 tips to increase your value

  1. Comment your deliveries
  2. Think before code
  3. Lesson learned

It is Lunar New Year. If you are looking for improvements, changes, those tips might be a good start.

Happy Lunar New Year! and Have Fun!