Much like the blank page syndrome for a writer, the unstarted project is a plague known to all developers. Often times, we tend to want to craft a perfect project. Most of the time, our ideas die in the bud. With the availability of powerful and often free resources, we have no excuse for not having anything concrete to add to our portfolio.

For personal projects, my suggestion is simple: everything is good. No unit tests? later! Are you using resources available in open-source libraries instead of coding everything yourself? Good idea!

The end goal is to have given birth to a project and made it available to the public. No?

Deploying less effort to achieve the results having the greatest impact.

At the workplace, always be harvesting the low-hanging fruits

If someone pays you to do a job: give them value for their money. Above all, do not waste your efforts to meet your ideals of clean code and compliance to elusive industry standards. Your client probably doesn't care.

When hired, be asking the following questions:

• Why does my client need this computerized system?

• According to what criterias is my work as a developer judged?

Unfortunately, you cannot avoid it: you absolutely must know why your client needs the computerized system on which you are called to work. Whether you work for a government agency, an insurance company, or a video game company, understanding the customer's needs is paramount.

By understanding the business domain, you will be able to:

• Communicate effectively with your client;

• Make informed decisions;

• Offer valuable advices.

This knowledge of the business area and the priorities of your client will also allow you to determine the criteria by which your work will be judged. Is it a ruse? Yes and no. No, because there is absolutely nothing wrong with focusing your work on meeting these criteria. Yes, this is a trick because knowing the customer's needs will allow you to achieve success with less effort than by working blindly; by relying on hypothetical a prioris.

Some developers mistakenly believe that their employer desires incredible productivity. They believe that by closing a significant number of tickets each day, they are doing a good job. However, this is rarely the case. Most of the time, these developers produce substandard code, don't test their changes well, and even slow down the process by having to rework a fix that QC has refused.

Other developers discover a passion for clean code, the SOLID principles and 'best practices'. For the same customer-perceived result, they will work harder and sometimes for nothing as the feature will be quickly dropped or greatly changed in a subsequent iteration. All in all, it is rare for a customer to value technical prowess at the expense of a functional and useful system.

Low-hanging fruits?

Knowing the business area, the client's needs and expectations allows you to identify these easy tasks that will have a significant impact on your client.

Here are some ideas that I have encountered in my daily life:

• Always validate and test your work before commiting code and closing a ticket;

• Consider as a priority any difficulty that blocks a member of the team and offer his help;

• Be familiar with the code, the data model and the deployment pipeline in order to inform the client of the risk or the extent of the planned work;

• Do not be too critical of the code: keep your code clean and refactor as needed in order to always be able to deliver the functionalities meeting the customer's needs.

As each of your clients experience a different reality, one should expect that these tasks will differ from one setting to another. The concept of "low-hanging fruit" is essential in development. Deploying less effort to achieve the results having the greatest impact.

Of course, some arduous tasks are inevitable. And by taking the time to understand the context of your intervention, you will save a lot of effort while effectively meeting your client's needs.