Context Engineer

'Context Engineer' is a term I first heard by Cris and Matt on the Claris AI Podcast.

It's essentially a natural evolution of 'Prompt Engineer' which focuses on AI and LLMs - this title lines up with a shift we’re starting to see where 'Vibe Coding' is becoming a thing - although Cris was using this term in the context of 'actual' Software Solutions.

If you ask ChatGPT - and yes, we seem to be switching to this as our 'knowledge' base - this result below is returned as the metaphor of how these titles differ.

Metaphor:

• Consultant: Architect (decides what to build).

• Developer: Builder (constructs the house).

• Context Engineer: Interior Designer (makes sure the inside 'works' for daily life).

I've personally struggled with the concept of Developer vs Consultant as the 'hierarchy' for those of us crafting Solutions with the Claris Platform.

And this may be the 'better' conversation we need to be having - how to separate ourselves from the Vibe Coders - and stand out as 'Context Engineers'.

Our role bridges between business needs and technical execution, ensuring that data and user workflows are always in the best 'context' - inside and outside of FileMaker’s schema & functions and within the business logic.

Context Engineer Checklist.

Here's a quick list of focus points :

• Strong Communication Skills

• Comprehensive Domain Knowledge

• Deliver what is needed, not wanted

• Watch for exceptions that prove the rule

• Know thy Solution Inside and Out

• Code to Troubleshooting

• Always be learning and improving skill set

Strong Communication Skills.

It's a skill in itself to ensure that all the Stakeholders - Management 'and' End Users - are serviced with their needs with your provided Solution.

This can sometimes having more than one story for the Solution, more than one point of view - more than one Context.

There's a political tight rope between Management and Users, which sometimes requires asking for forgiveness, rather than permission. See the role as the driver for the direction of the project. Remember, if the customer could do it for themselves, they would.

Exercise: Record yourself presenting the solution to multiple groups - you'll be surprised as to how each group's presentation differs, and how well you know the solution.

Comprehensive Domain Knowledge.

Context requires a clear understanding of the environment in why, when and where the solution is expected to perform.

Over the years, there have been notable examples of where lack of communication with the requirements has led to a misfit of the solution to the problem. Examples of this include the presentation of data much larger for retired volunteer users and big buttons for 'Tradie' Users on the iPad.

Management requesting Invoices to be viewing in a day view, while the sales staff are called by the customer to update their order by the week, with the requirement to enter the week's quantities for a product - 5, 4, 6, 3, 5, 6, 2 - verbally over the phone.

Exercise: Attend a workday with the end user - in person - and simply observe the current workflow. See how the data follows, see the context of the work performed, and the outputs required - don't assume.

Deliver what is needed, not wanted.

I've written and spoken about this many times - although it still needs to be repeated. This is a similar concept to the Domain Knowledge, with a tighter focus on the features themselves.

We've recently completed a project where the previous Developer provided what Management wanted - rather than what Users needed.

Simple feature request to be able to allocate Equipment to Personnel. Admin table of Equipment, with allocation table related to Personnel. Or is it ?

The data provided what was needed. At any one time, 8-10 pieces of Equipment would need to be added to anywhere from 10-150 Personnel, based on multiple Roles assigned to Personnel, with crossovers of the same Equipment for similar Roles.

A Role layer was included with the solution, where the Equipment was Assigned to the Role, along with Personnel assigned to the Role - with the requirement that anyone piece of Equipment not be assigned more than once.

The outcome of this new function is that 'teams' of Personnel can be allocated - and un-allocated - equipment in minutes, rather than hours.

Exercise: Review a recent function crafted for an end user, and count the mouse clicks. Mouse fatigue is a real thing - not to mention the enemy of new features.

Watch for exceptions that prove the rule.

This one pops up every other day. You know the situation when you craft a clear path based on the requirement - and the true data was omitted or excluded from the brief - and the decision to change paths is needed. This is where building from just the proposal fails.

The function to assign Equipment outside of the Role was kept, for the exceptions where a Role was not required, no need for a single Role for a single Personnel for Equipment.

Exercise: As part of the QA Process - challenge your End Users to break the system - even gamify the process - you'll be surprised with they may come up with.

Know thy Solution inside and out.

The best way to have a clear view of your Software Solution - and in this context of Claris FileMaker - is to run a DDR Analysis Tool.

Knowing where each Element - let's discuss fields in this case - is referenced is critical in providing the correct context when performing updates or troubleshooting.

It's now even more important these days to know when elements are referenced outside of the solutions. This includes Data API calls, eSQL Calls, and even AI functions & reporting.

This includes documenting all the moving parts of the Solution for the Customer and of course Developer Next.

Exercise: Step back - and imagine that you've been 'Hit by a Kangaroo' - what documentation have you left for Developer Next and the Customers - now build that information and publish to those who will need this.

Code to Troubleshooting.

This may seem obvious, most Developers don't seem to code to allow either User or Developer Troubleshooting in multiple situations, especially allowing troubleshooting 'transactionally' to allow reversing out of scripts without touching data in the LIVE system.

This starts with basics of collecting data in variables at the start of the script, validating and then updating data in temp tables, before touching live data.

A simple comment at the top of the script to define data sources and troubleshooting environments can save Developer Next hours in lost time.

Exercise: Open a recent solution and see which functions and scripts can - and more importantly can't - be run by yourself as Developer Next.

Always be learning and improving skill set.

This one is key to our industry. it's no good to be coding with old 'FileMaker 6' methods in today's world - you get left behind, as does the Platform and Community.

This is true when it comes to Vibe Coding - learn how this process will compete or add to your tool belt of tricks. Think of this as the updated version of the Custom Function Website.

Exercise: Spend some quality time on the Claris Academy and the multitude of Credly badges available for all the great new features we have - especially those relating to AI.

Take Away.

It's worth considering the 'philosophy' and of course 'methodology' of how & why you craft your code. This includes how you promote yourself, and how your Stakeholders perceive your benefit and/or worth.