When the 'client' makes a request, we must parse it.

We take that information and try to make sense out of it.

Perhaps the client needs a solution to a common problem, or a bug fixed.

Our job, as the 'server' is to handle that request and return to them a suitable response.

But before we write any code, lets just begin by asking a preliminary question...

Do we even need to write code?

Code does not always have to be written in programming languages

Before even considering a solution, you should be absolutely certain what the problem is.

Finding a way to verify and document the issue is a good way to begin your dialogue with the client.

Already, through the process of documentation we begin to write the 'codeless code'.

You may be taking notes, sending emails, writing reports, presenting your discoveries!

Gaining a full understanding of the issue and being able to explain the process is gold.

A well-written document, a tangible token. This response is better than only giving a verbal explanation.

There may be 'nothing' to do

The first possibility is that the client could be mistaken.

While it may be easier to just give the client what they asked for, we want to provide real value.

Especially when dealing with non-devs, there is often a misunderstanding of a technical problem.

You may discover that there was actually nothing to solve to begin with.

Great!

However this does not mean that you haven't done anything.

You will have provided insight which helps to enlighten the client to a new understanding.

A non-code solution

Writing and maintaining new code can be a lot of effort and cost.

Can we find an existing solution, or one that takes less resources?

As I was told as a child "Just because you can, that doesn't mean you should".

Rather than creating a custom product, there may be one that can be quickly employed.

Finding a sustainable and reliable solution, may be a simple query search away.

As they often say in programming culture, "There is no need to reinvent the wheel".

Building something completely new should be a last resort unless its for personal development.

A thousand ways to approach writing code

Once a decision has been made to build it, we have to find the right tools for the job.

The more tools we have, the more complicated the situation becomes.

Complexity is the mother of all bugs

Are the tools reputable? The languages, the packages, the architecture, etc.

For how long can this piece of software be easily maintained?

Sometimes, even after one month, you find your dependencies have all been deprecated.

Ordinary code is maintainable code

One of my favorite design principles has been "Keep it simple stupid" KISS.

By writing idiomatic code, and upholding common practice, you become the superior programmer.

Trust your intuition when it feels like you may be headed into the weeds.

Almost every common task has already been solved in a concise manner.

To attain this sublime practice, you must completely cut off the way of cleverness.

Knowing when to say NO

You may be dealing with a stubborn client, or an unmaintainable legacy code base.

Know your limits!

Before moving forward, take some time to evaluate instead of rushing into an agreement.

Saying no to this opportunity may free your time for something better.

Or it may just give you peace of mind, which is priceless