experienced engineers pattern match

Software engineering is complex not complicated.

Developing software is often more complex than it is complicated. That’s to say; the number of components involved in the development of a non-trivial system is large enough to increase the complexity. Complexity is not difficulty.

Complicated refers to the difficulty level, there might be few components but it will take a lot of hard work to solve.

Given many of the jobs of software engineering can be distilled down to…

marshalling and unmarshalling different data in and out of different databases

…and many of the problems that we wish to solve consists of gluing the correct components together in (possibly) novel ways. I assert that development is more complex than it is complicated.

Experienced engineers pattern match faster.

Given experience in this context is…

the knowledge or skill acquired by a period of practical contact with facts or events, especially that gained in a particular profession.

practical contact with and observation of facts or events.

It’s generally implied that experience is a good thing, and that past contact with an event or fact will be useful in future contact with that event. What is suggested when we describe an engineer as experienced is; they have the practical contact with an observation of facts or events that will allow them to make more informed and better decisions the next time they encounter those facts or events.

Experienced engineers can transfer domain, technology stack and projects and still be able to exploit their previous contact with events. This is because software engineering is complex and not complicated. An engineer may work across different domains, different tech, different stacks and different projects, but an they will still handle similar reusable components in similar ways. This allows them to exploit the knowledge from previous similar experiences.

Using prior knowledge becomes a matter of taming complexity by being able to assert if a given problem or event is just another one of those.

Experience becomes the ability to pattern match the current situation to past ones, and the ability to see similarities in events that can be exploited to handle the complexity.

As a real-world example, there are some engineers on the teams that I work with who need to see some code once, and are able to pattern match to the previously seen example. Being able to review a PR and know next time in their own code that some testing framework has a MatchJSON(...) matcher.

Experience as an engineer becomes a function of an individuals ability to pattern match scenarios to previously encountered facts and events. It’s strictly not the number of previously encountered events for an individual (or a proxy for “number of year doing the task”).