Imprecise to Precise

What makes a great engineer? Their ability to build the right amount of context.

Software engineering is the art and science of going from the imprecise to the precise.

The input to the process of software development is fuzzy.

Sometimes it’s more fuzzy, sometimes it’s less fuzzy:

👉 “Build a feature to do X”
👉 Marketing requirements (MRD), Product requirements (PRD), and functional specifications.
👉 Various design specifications (UI, UX, etc).

The software engineer will take those items and produce something very precise: software code.

It will leave no room for ambiguity. Software must be told what to do in every possible instance.

If it doesn’t, it’s likely going to crash or at least produce a very crappy user experience.

💡 The job of the software engineer is to fill in all these gaps.

However, context is critically important in moving from the imprecise to the precise. Without this context, there would be a mechanistic way to do this.

Every day, there are tens of choices to be made, and the engineer has to fill those with context.

So, what separates a good engineer from a bad engineer?

❓ Is it how much context they have? Maybe that is one factor, but nobody ever knows anything from the beginning.

❓ How about their ability to get context? That's better, but that can also go wrong with “analysis paralysis,” where we try to find out more and more about the problem without solving it.

👉 The better answer is that the good engineer will find the correct amount of context that will enable them to make sufficient good decisions in converting requirements to code so that they can be quickly tested with users.

Collaboration skills are key.

With those learnings in hand, the process can be repeated as many times as necessary to improve the end result.

How is this actionable?

Hire engineers who are good at collaboration. 🤣

But there is more to it. Most software is not written by a lone engineer. It is written by a broader, cross-functional team.

So, on your way to an effective, happier way of building software, consider:

• How does context flow in your team?
• Where are the barriers to collaboration?
• Where do miscommunications take place?
• What frustrates the team?