42: Or, the key skill needed for everything An introduction to Problem Solving

The main skill required to achieve proficiency and even mastery is problem solving. In India, when you hire WordPress developers, you often hire people with some development background and then you train them (or provide a self-learning roadmap like this one) to become a WordPress developer.So, to make a hiring decision, some people ask a logical problem and expect the candidate to work out an algorithm in layman terms. If the candidate can work that out, they can take on any complex WordPress problem, in the future.

That’s a better investment than hiring someone who has good knowledge and experience with WordPress but no problem solving skills.So, a major focus of this roadmap is towards problem solving skills, directly or indirectly. In this post, we’ll try and understand some fundamental concepts in the science of problem solving. When you solve actual real world problems in when working on client projects or building products, you won’t care what kind of problem it is. It’s not necessary to remember any of this but it is necessary to know.

Understanding a problem

Problems are described as having a beginning state and a goal (the solution). The act of problem solving is described as taking actions to progressively move from the beginning state and end up with the goal. There may be various constraints that may affect what actions you take or how you perform those actions.

This roadmap itself is a problem. There is a beginning state which we’ll describe in the next post and there’s a goal which we’ll describe in the post after that. But, by intention, this roadmap is for a beginner WordPress developer who wants to become a beginner at WordPress engineer. This roadmap describes the steps (actions) to take to reach our goal. That’s problem solving.

These four attributes of a problem (beginning state, goal, actions and constraints) may be well defined or not be defined, at all. Depending on how well these are defined, there are three kinds of problems:

Well-Structured Moderately-Structured Ill-Structured
Goals (end state) well defined usually well defined undefined
Beginning State well defined well defined well defined
Actions (process) well defined many possible actions undefined
Constraints well defined usually well defined usually not well defined
Examples Releasing a new version of a theme/ plugin.

Building an e-commerce store using WooCommerce.

Fixing a PHP Fatal Error

Fixing a hacked WordPress site

Optimising a WordPress website for speed

Building an e-commerce store for selling digital goods.

Well-structured problems

Also called rote problems because if you learn the steps involved, without any deeper understanding, you’d still be able to solve the problem. This also means that the solutions can often be automated. This also means you don’t need to memorise them, the steps are available somewhere as a reference, tutorial or a cheat-sheet that you can look up when you face the problem.

Example: Releasing a new version of a theme/ plugin

Once all the changes to the code are done and a theme or plugin is ready to be released, there are well-defined steps that you need to take to release them on git, WordPress.org or a premium store (your own or third party). You may have a list of commands that you have to run, one after the other. You may do that without understanding why or how they work and still be able to release a theme or a plugin.

Example: Building an ecommerce store using WooCommerce

It is a very straightforward process. There are set steps you need to take, install/build a theme that supports WooCommerce, install WooCommerce, setup payment and shipping gateways, insert products, a couple of other steps and you are ready to go.

Moderately structured problems

They have some of their attributes defined pretty well. The simplest type of moderately-structured problem solving is troubleshooting. You know the beginning state (site with an error), you know the goal (error-free site), you pretty much know the constraints (environment, plugins, themes, etc). You just need to figure out the process or the actions you need to take. Depending on your knowledge and experience, you’ll either use blind trial and error to solve the problem, look up to see how others have solved the problem and try those or define the problem space, form assumptions (looking up other similar problems helps) and then test your assumptions one by one.

Example: Fixing a PHP fatal error

Let’s say you get a fatal error in PHP that says something like:

There are multiple ways to solve this problem once you get more information. First is that probably the file is in some other path and the defined path needs to be corrected. Second, the path is correct, but the file is missing. Maybe it is yet to be created or was removed in a recent version but the include statement still remains. So, you’d either create the file or remove the include statement.

With enough experience, expert engineers can come up with a standard process (turning things into a well-structured problem) like this one. You may often get such troubleshooting checklists at organisations. However, everyone involved in creating and using such a checklist knows that there will be cases that won’t be solved using the checklist and the checklist just rules out common scenarios and reduce the unknown.

Example: Fixing a hacked WordPress site

It can mean multiple things. Depending on what has happened, you may want to clean the website, restore it to a previous version or do both of them in alternate order. You may also want to investigate the cause and the security hole and plug it. Depending upon your experience, the cost involved and the time available, you may just want to restore the last unhacked version and then do the remaining afterwards. You may want to invite a security expert or just move on and repeat the restoration the next time it is hacked. You need to decide what to do and how to do it to achieve the goal of a un-hacked WordPress site from a hacked one.

Ill-structured problems

These are the most common problems that you’ll get as a WordPress Engineer. You’ll have to come up with multiple possible solutions (or end-states/ goals) and explain your rationale behind those solutions. Once all the stakeholders decide on a particular solution carefully considering all the constraints (of time, effort, complexity, cost, etc), you have to come up with the best process, given the constraints to reach a solution. In practice, engineering is converting ill-structured problems into well-structured problems and then implementing solutions.

As a beginner, depending on the size and the structure of your organisation, you’ll have someone (project manager, team leader, client) do the structuring for you so that you only have to work on the well-structured problem (implementation). This is often done as part of the requirement analysis. While implementors, builders, coders or developers only implement the solution, engineers are often involved and have a say in requirement analysis.

Example: Optimising a WordPress website

It can mean different things in different contexts. You have to decide the things that you possibly can’t do anything about (ad and social scripts loading from multiple domains) or the time and resources you have for object caching (like on shared hosting) or page caching (you can’t cache some pages for example, in WooCommerce). So, you have to decide on a practical goal, explain it to all the stakeholders, agree upon it and then implement it.

Example: Creating an e-commerce store for digital goods

Right at the beginning, you have to choose a development goal, i.e. whether you’ll be using EDD or WooCommerce.

Problem Solving in the Roadmap

Most tutorials, howtos and courses you’ll encounter in your journey as a learner work with well-structured and moderately structured problems. However, the majority of learning and the most effective kind of learning happens when you solve ill-structured problems. That is why there is so much emphasis on self-learning and on-the-job learning in the actual industry. This roadmap aims to get you to a place where you can attempt ill-structured problems. We’ll talk about this more when we discuss the Always ask, “Why?” rule.

Roadmap as a Problem

The next post onwards, we’ll analyse and describe this roadmap as a problem and define its problem space (or attributes). In one post, we’ll understand the beginning state by figuring out what we mean by a beginner. In another, we’ll understand the end state by figuring out what we mean by an engineer. In a third post, we’ll discuss the constraints and finally, we’ll discuss an overview of the process. We’ll try and understand if this is a well-structured, moderately structured or ill-structured problem and then solve it accordingly, in the remaining posts.

This part of the series will be really useful if you are a stakeholder or manager of training or learning processes within your team.

1 Response

What do you think?