How to Think Like a Software Developer

Any sufficiently advanced technology is indistinguishable from magic.

Arthur C. Clarke

When most ordinary people think of software and computing machines they usually perceive it as some sort of complicated and mysterious system of engineering, a black box of wonder capable of making the impossible seem possible.

Introduce a child to a touchscreen device and a virtual reality experience and the most likely form of reply he will give you is that it is a form of magic, something beyond the stories he has heard of from old books and weary relatives.

As the people that work on these machines we must seem like a sort of bizarre crowd.

We spend our days in solitude doing most of the following:

• Staring at a glowing screen as if looking for an answer.
• Reading technical books full of unusual terminology.
• Talking about cryptic languages most people do not understand or use.
• Writing hundreds of lines of code that make no sense to the average eye.
• Communicating with a group of foreigners via a worldwide network of devices.

Does this seem strangely familiar to you?

Upon further thought, have we come far enough as to blur the line between reality and fantasy in terms of what we can achieve using our knowledge?

Software as a Form of Magic

I believe that a good software developer is like a good magician in the classical, fantastical, sense of the word.

He is someone who endeavors to bring change into the universe through words and ritual alone. Using a specific set of words with very special properties and occult meaning: a programming language.

These words serve as his sorcery; being no less mesmerizing than the grey cloak and the Wizard’s hat that have captivated our writers for centuries.

Fortunately for us, our modern tools are deterministic. Which means that our words will always have a known and intended effect every time they are interpreted by our machines in the same ritual of execution.

The Realm of Problems

In order to bring change into the world, a developer must be confronted with a problem or (if the problem is too broad) a set of problems.

There are, broadly, three categories of problems defined around the existence or non-existence of some thing:

• Something that does not exist.
• Something that exists but is not working properly or desirably.
• Something that exists but is unknown or incomprehensible.

A problem serves as a trial, or an opportunity for the developer both to solve a problem and grow as a practitioner.

A developer can bring something into existence by arranging his words into a cohesive abstract system of moving parts.

He can delve into someone’s work, understand his particular system of parts, re-arrange it, and expand the system to meet new expectations.

He can create his own implementation of something that already exists, for the sake of knowledge and experience as if to gain some sort of acquired power.

The applications are endless for the software developer.

He examines a problem that can be solved by the application of technology, devises a solution, implements it by a series of elegant machine commands, and changes a small (or large) part of the world forever.

How to Conquer a Problem

Now that the role and the craft of a developer are understood, what is left is a manner of dealing or thinking about problems effectively.

As powerful as a software developer can be, his knowledge and tools can only be as effective as his understanding of the problem.

If he does not understand a problem his solution will not understand his requirements as well, and we should not assume otherwise.

In this case, I defer to Mat Helme’s work on problem solving, which should be considered our guide to thinking like a developer in a practical sense.

Briefly, a general way of dealing with problems can be summarized in the following four points, known as the Four P’s of Problem Solving:

The Problem Solving Process

The first step is prep, this is where we understand and diagnose the problem.

Then our next step is plan. This is where we organize everything before acting.

The third step is perform. We simply put the plan into action.

Then our final step is perfect. This is when we check to see if our end goal has fulfilled the problem. If not we can go back, review and rework the solution.

Mat Helme

Laced throughout this process is the concept of experimentation.

There can be no problem solving without both curiosity and experimentation. This is where the act of software development approaches science in spirit.

Problem Solving Is Science

In fact, the scientific method itself can be seen as a cyclic or recursive application of the Four P’s of Problem Solving:

1. The preparation stage is used for making observations about a part of the world (a system).
2. The planning stage is used for formulating hypotheses and predictions.
3. The performing stage is used to gather data, results, and study the outcome.
4. The perfecting stage is used to revise, refine, or discard hypotheses in accordance with real-world results.

The parallels seem to suggest that the developer as a problem solver is not very different from the scientist.

They both make observations about a system, formulate hypotheses or guesses as to why the system works a particular way, postulate predictions about future behavior under certain circumstances, and test them under a controlled environment to examine their validity.

The difference is that the developer does not need thousands of dollars in government funding to carry out his experiments.

He can do them at will, in quick succession, and at little to no cost in most cases. This itself is another magical property of the work of the developer, in that it usually does not have any physical constraints and thus, no limits to the amount of work that can be carried out.

More Than a Thought

To put into practice the act of thinking and acting like a software developer, we must continually approach problems armed with the following:

• A problem-solving methodology (the four P’s).
• A set of tools (programming language, libraries, framework, etc.).
• A set of rules to reason about the system we wish to change or create (logic, induction, deduction, and pattern-recognition).
• Time, hard work, perseverance, curiosity, and experimentation.

Additionally, good software developers tend to be good computer scientists, which mean that beyond their thought process, they also have knowledge of algorithms, data structures, and design patterns in particular, as well as a good grounding on best practices.

These are the secrets behind the magic that allow the individual to write code that can both change the world and be used by others in their own path to build a different vision of reality.