Core engineering you still need

The engineering base customer-facing roles lean on every day: a scripting language, SQL, HTTP, Git, cloud basics and the skill of debugging systems you did not build.

A glue language

Also called Python, TypeScript, scripting

What: One language you can write quickly and well for scripts, small services and data jobs. Python is the usual choice, with TypeScript close behind for web work.
Why: Customer work is mostly glue: moving data, calling APIs, wrapping a model. Fluency in one language makes you fast when a customer is watching.

Watch out

Spreading across five languages at a shallow level instead of being truly fast in one.

SQL on someone else's data

Also called SQL, data exploration

What: Reading an unfamiliar schema, profiling tables and answering questions with joins and aggregates, often in the customer's own warehouse.
Why: Most customer problems live in their data. Being able to check a claim with a query in minutes changes the conversation.

SQL

-- first look at an unfamiliar table
SELECT COUNT(*) AS rows_total,
       COUNT(DISTINCT customer_id) AS customers,
       MIN(created_at), MAX(created_at)
FROM orders;

Watch out

Trusting column names: status may mean three different things in three systems.

HTTP and REST basics

Also called HTTP, REST API, status codes

What: How programs talk over the web: a request with a method, URL, headers and body, and a response with a status code and body. REST is a common style for organising those URLs.
Why: Nearly every integration is HTTP. Reading a failed request and its status code is the first step of most customer debugging.

Shell

curl -s -X POST https://api.example.com/v1/tickets \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title": "Printer offline"}' -w "%{http_code}"

Watch out

Retrying every error the same way: a 400 needs a fix, a 429 needs waiting, a 503 may pass.

Git in a customer's repository

Also called Git, pull request, code review

What: Branching, small commits and pull requests in a repository with someone else's rules, reviewers and pipeline.
Why: Your code only counts once the customer's team accepts and can maintain it. Following their conventions earns that.

Watch out

Pushing a large change in one pull request that nobody on the customer side can review.

Cloud basics

Also called IAM, VPC, AWS, Azure, GCP

What: Enough of one cloud to deploy a small service, store secrets, read logs and understand identity and access management (IAM) and private networks (VPCs).
Why: Enterprise customers run on a cloud, and most blocked deployments are really permission or network problems.

Watch out

Asking for broad admin access to move faster, which security teams rightly refuse.

Debugging systems you did not build

Also called troubleshooting, root cause

What: A method for finding faults in unfamiliar code and infrastructure: reproduce, narrow down, form one hypothesis, test it, repeat.
Why: At a customer you rarely know the system, and people are watching. A calm method beats guessing and looks competent.
Example: An export fails nightly. Reproduce with one record, check logs for the time, notice a time zone boundary, confirm with a record created at 23:30, then fix the date handling.

Watch out

Changing several things at once, so even when it works you do not know why.

Reading logs and traces

Also called logs, observability, tracing

What: Finding the lines, request IDs and timings that explain what a system did, across application logs, cloud logs and traces.
Why: Logs are usually the only witness to a failure that happened overnight at a customer.

Watch out

Logging customer data or secrets while debugging and leaving it there.

Go deeper