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.

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.

How to Make It as a Mediocre Software Developer

If you’re in the software world, chances are you’ve felt overwhelmed with the amount of work and effort required to be competent and keep your skills up to date.

As a developer, this thought shouldn’t scare you. Making good software is hard. Humans make mistakes, and machines remind us of that. It’s all so unpleasant, you see.

Therefore, it completely makes sense that you wouldn’t want to spend the majority of your time on a never-ending struggle with a machine and would rather enjoy yourself more often than not.

And that is totally fine. Thousands of other developers are already doing just that.

What follows is my best advice on how to become a professional enterprise software developer and enjoy a comfortable career with minimal effort.

1. Don’t Ask Any Questions

The best people are the ones that ask the right questions. But forget that, being the best means working hard. And working hard means, well, working.

The best technique is to say nothing and nod confidently in understanding.

If someone attempts to pry, you can condescendingly reply with a nonchalant ‘I know what I’m doing’ or scoff at them with slight disbelief.

Doing so would get you into trouble if you were, say, a brain surgeon or an emergency anesthesiologist. But you’re a developer and you have three indispensable tools at your disposal which almost guarantee that you don’t really need to know what you’re doing:

  • Google
  • Stack Overflow
  • Ctrl + C / Ctrl + V.

Which is exactly why you should move on to the next point on this list.

2. Say ‘Yes’ to Everything Your Boss Says

Nobody likes saying the word ‘No’. But you know what people hate even more than that? Hearing the word ‘No’.

If there’s anything you should learn from politics is that naysayers stay at the bottom of the ladder. You want to be the Yes-man.

It doesn’t matter that the boss or client has no idea of what they want, or that there hasn’t been any product design planning made beyond a few minutes of conversation, or that nobody has any clue of the complexity of the problems that your team will be facing or even the tech stack that you’ll be handling.

Just say ‘Yes’ and smile. If it works for management it’ll work for you.

3. Let Your Teammates Handle It

A great asset for disguising your mediocrity is other people. You should always seek to work in the largest teams because as more people tend to work on a project it becomes harder for management to keep track of who is responsible for what.

And more people means you can use your flattery to extract help and hide behind the accomplishments of your teammates.

Whenever something goes wrong or you have no idea what to do, you can seek out one of the more competent people you’ve buttered up over the past couple of weeks and ask ‘what they would do in your position’ and steal their ideas for your own use.

Their poor social skills in most cases will work for you and you’ll be able to bill yourself on your résumé as a ‘strong team player’.

4. When in Doubt, Blame I.T.

As a developer, you know you’ve made it when you see one of the lowly I.T. “people” have to painstakingly deal with broken Windows upgrades or Hard Disk Drive failures while you sit in your comfy padded chair with your colorful IDE open and a few Reddit tabs on the background.

‘Heh’ you might say to yourself while you shrug and get back to “work”. But stop right there, for this situation presents a unique opportunity for the rare times when you are asked to explain yourself.

You can now blame the I.T. department.

From everything to data loss, password resets, hardware “failures”, administrator access, user permissions, and more. ‘Waiting on I.T.’ or ‘I.T. screwed up again’ is the perfect excuse to enjoy your lack of productivity at someone else’s expense.

5. Hide Your Development Tools

Development tools are designed to be efficient and save time. They are not your friends. If you can cut down on building or deployment time, that is time that you will be expected to be performing additional work.

This is of course, highly undesirable. However, with a little cunning you can make your laziness work for you. Perhaps make one of your co-workers help you write a script to automate some mind-numbing task or get on GitHub and find a gist that does what you need to skip some long repetitive work.

The key is to keep these tools and hacks hidden away from management. You can now enjoy the rest of the time that these tasks would regularly take and maybe even take some credit for finishing earlier than expected.

Oh, and definitely do not share your development tools with your co-workers. If they can’t keep quiet about them then they don’t deserve them.

6. Don’t Document Your Work

Documentation usually means that there is some sort of forethought or emphasis on the future at your company. You should absolutely be discouraging this sort of behavior from your employer. It is just completely unacceptable.

You should never write more than two lines of comments or a few words in your commit messages, or even follow standard design patterns or coding conventions.

Those are things for the lead engineers to worry about. You’re a professional and an adult, you don’t need to explain yourself to anyone and much less waste time worrying about how the system is going to scale, the maintainability and efficiency of your code, or other trivialities.

7. Spend All of Your Free Time on Entertainment

Finally, here is where you get to enjoy the fruits of your labor: a lifetime of choice entertainment, constant outings with ‘the boys’, a long string of drunk nights out, and enough stories to make the bigwigs over at lunch fall off of their seats with riotous laughter.

Or maybe you’re the more introverted type. In that case, you get to look forward to a big Steam library, terabytes of obscure Chinese cartoons, and Lord knows what else you might end up having lying under some AES-256 encryption in your SSD.

Don’t worry about reading technical books, contributing to open source software, listening to podcasts, taking online tech courses, or even having some personal passion project at home. Those things are for sweaty geniuses, autists, and future mass shooters.

You know better than that.