Mayhar Jabbo

Engineering

How I engineer

Five principles, the layers I work across, and the failure modes I design around. Each principle came from owning production systems after launch, when design choices become operating consequences.

Principles

Principles shaped in production.

These are working rules drawn from systems that had to remain safe, explainable, and supportable.

  1. 01

    Configuration over duplication

    When behavior can be expressed as metadata, build the framework that reads it instead of another one-off integration. Connections, source objects, load behavior, transformations and destinations belong in configuration, so onboarding a source becomes a configuration change.

    The Databricks ingestion framework and the ERP-to-SharePoint sync both work this way.

  2. 02

    Verify the system, not the label

    Legacy systems are full of fields whose names do not describe their behavior. A column called speed may hold seconds per part; a description field may contradict the code field beside it. Establish what a value means from the data, the audit history and controlled tests before building on it.

    Determining the units, grain and reliability of MES production metrics before exposing them.

  3. 03

    Safe writes first

    Before an application modifies a production system, build the guardrails: a dry run that reports the exact create, update and delete plan; writes disabled by default; guards against a failed query emptying a destination; transactions; rollback testing against live data. Prefer the vendor's own supported entry points over direct table writes.

    Scrap and downtime corrections in the MES dashboard, and the reconciliation guardrails in the ERP sync.

  4. 04

    Put computation in the right layer

    Expensive transformation logic should not stay in the semantic layer just because that is where it started. Moving work into SQL, Spark or the source system improves refresh time, resource usage and maintainability at the same time.

    Rebuilding Power BI models whose logic had outgrown Power Query.

  5. 05

    Documentation is part of reverse engineering

    When undocumented behavior is worked out, the finding is part of the deliverable: the evidence, the assumption that was tested, the grain, the units, the failure modes and the safe way to change it. The goal is for the next engineer to understand why, not only what.

    Every case study on this site started as a written finding in a repository README.

Scope

The useful work is between the layers.

This is the range I have built in and supported. A typical project crosses several layers, and the difficult failures often appear at the handoffs between them.

  1. 01

    Machines and sensors

    • Injection presses
    • IoT signals

  2. 02

    Plant and business systems

    • MES
    • ERP on IBM i

  3. 03

    Databases and interfaces

    • SQL Server
    • REST APIs
    • SharePoint

  4. 04

    Ingestion and integration

    • Python / Spark
    • C# / .NET
    • Node.js
    • PowerShell

  5. 05

    Lakehouse

    • Azure Databricks
    • Delta Lake
    • ADLS Gen2

  6. 06

    Serving

    • Semantic models
    • Views
    • Internal APIs

  7. 07

    Consumption

    • Power BI
    • Internal applications
    • Plant floor
A map of the layers I have built and supported, not a single company's architecture. Most projects touch a handful of these; the point is that the boundaries between them are where the work usually is.

Analytics

Most Power BI problems are not Power BI problems.

My Power BI work usually begins below the report: reliable refreshes, efficient capacity use, clear semantic models, and moving logic that belongs elsewhere.

When a model is slow or a refresh fails, transformation logic has often outgrown Power Query. I trace dependencies across reports, measures, calculated columns, and source tables, then move expensive work into SQL or Databricks where it can be incremental, tested, and monitored.

When the built-in visuals cannot express an operational layout a team already relies on, I build the visual in TypeScript instead of distorting the data model to fit a chart.

Areas covered

  • Enterprise semantic models
  • DAX
  • Power Query / M
  • Power BI and Fabric
  • SQL-backed transformations
  • Model optimization
  • Query folding
  • Gateway troubleshooting
  • Privacy-level issues
  • Refresh reliability
  • Memory and resource governance
  • Capacity optimization
  • Custom visuals

Next

See the principles in practice.

Each case study connects these principles to a production system, its constraints, and the decisions that made it reliable.

The MES dashboard is the clearest example of verifying a system rather than its labels, and of guardrails before writes. The ERP integration is the clearest example of configuration over duplication, and of a reconcile that stays safe when its source misbehaves.

Read the case studies