The goal of this roadmap How is WordPress Engineering different from everything else?

Who is an Engineer?

I mentioned at the beginning of this series that what I mean & understand by WordPress Engineer is different from what I understand by WordPress Developer. To-may-toh, to-mah-to? Not really.

In my eyes, there’s a clear distinction and it’s not based on one’s ability to code. So, I’m really not interested in distinguishing an implementor/ assembler or similar terms that attempt to differentiate the ones that can code custom stuff and those who can’t.

WordPress Developer

A WordPress Developer according to me, is someone who can build features, either by installing a theme or plugins or creating custom ones. They can write code and even implement complex code (whether by copy-paste-modify or from scratch, it really doesn’t matter).

If you’ve attended any training session or workshop with me, I frequently ask learners to look at dictionary definitions of technical terms. Not in a technical or specialised dictionary, but regular google.

That’s mostly because those words have existed before they got their specific technical relevance. So, the dictionary definition always helps in getting a deep fundamental understanding of anything. For example, see the definition of the verb engineer:

Engineer Definition

The one that we’re interested in is highlighted.

WordPress Engineer

A WordPress Engineer, thus, according to me, is someone who first designs a solution and then writes code by this design.

Engineering by Design

Design Definition

I recommend reading a quick overall summary of the Engineering Design process here:

Once you’ve done that, please read this excellent post that delves into Engineering Design at a much higher and detailed level: Here are a few excerpts/quotes:

Design begins with the recognition of need and follows an intentional process by which you apply knowledge and actually make products to effect change. It is central to innovation. It essentially is the process of innovation.

Technology-driven design often results in products looking for a need. Human-centered design always keeps the needs of end users in mind. Design for humans needs to begin with developing understanding and empathy for human experience. It applies science and technology but also includes insights from the humanities and the social sciences. Engineers often love to jump right into making things, but early in the design process it’s often preferable to focus on deeply understanding the needs of end users.

In addition to a pleasing look and feel, human-centered design explores opportunities for innovation in interface design, ergonomics, function, and use. Great designs do it all.

Since the explosion of competition globally, design has become the best way β€” or only way β€” that companies differentiate their products. It has developed into a key aspect of innovation and a requirement for success.

The key to Engineering by Design

The key to engineering by design is empathy, in my view. I don’t mean empathy like sympathy or an abstract feel good emotion. I mean empathy as design goals that you build using user stories. Goals that you test using user testing. Goals that you revise using user feedback.

Such empathy or user centered design goals cannot be created or implemented if there is no enquiry into the purpose of every decision you make while engineering a solution. As long as the purpose is aligned with user need, you end up implementing excellent solutions. The moment the purpose of engineering gets disconnected from actual human needs, you’re just building excellent technical stuff that can be incredibly frustrating for users and you’ll keep wondering why your users are such a**holes to you all the time! πŸ˜‰

That’s why, the “Always ask, Why?” step is number 1 in my list. You can’t be an engineer without enquiring into the purpose of the tools, processes and software that you work with and solutions that you develop.

The goal of this roadmap

At the end of this roadmap, I expect a learner (you) to be able to:

  • Define a development problem in terms of end-user goals.
  • Ask how and why to perform background research.
  • Convert the user goals into development requirements.
  • Brainstorm multiple solutions.
  • Choose the one that is the best for the problem, given the constraints, if any,
  • Build a prototype of the solution.
  • Test and redesign the solution based on stakeholder (client) feedback or user-tests.

See, there’s no mention of WordPress, PHP, jQuery or any Javascript frameworks above. Like I’ve said before, if your fundamentals are in place, everything else becomes extremely easy.

We have defined the beginning state and the end state of the roadmap (which itself is a problem to solve). Next post, we get into the constraints of the roadmap (or a learning context, in general).

What do you think?