Edit

Surface area of being a "standard" engineer.

The in's and out's of a language may be the least important things to have competence in. The surface area of a professional level body of knowledge for a competent engineer is fairly wide. Here's a mind dump

I’m not talking about a rockstar engineer level, I’m talking about being a standard engineer. The one who shows up and gets it done. They may not always be the fastest, but they are predictable. Maybe their senior and maybe they’re not. They may not come up with the most intellectually wonderful solutions, but they never deploy garbage. A good old, standard engineer. Perhaps that’s how I like to think of myself.

I got to thinking, what would the surface area of their knowledge look like?

There’s no conclusion to this post it is simply meant to be provocative.

The list

Language

This was the list that started this entire post off.

  • Syntax
  • Standard library
  • Idiomatic patterns
  • Modules
  • Packaging & packages
  • Testing
  • Compiling
  • Debugging

Frameworks

Not necessarily these frameworks, but an understanding of why you’d use one vs writing your own HTTP handlers or database abstractions over raw SQL.

  • Web - Rails, Phoenix, Django
  • Database ORMs: Ecto, ActiveRecord
  • When not to use them

Inter-personable

These are in bold because they, to me, are negotiable. Everyone has a fundamental right to feel comfortable in their working context.

  • Open and welcome to everyone regardless of any characteristic or trait they may or may not possess.
  • Tackles any flavour of toxicity in a professional and calm manner.
  • Handling disagreement on decisions professionally.

AI

AI is in the workplace and I doubt it is going away any time soon. Understanding how to use it to increase output whilst not defecating all over the future of the codebase is essential. As is the basics of how the technology works.

  • Can work with or without AI assistants
  • Prompting: clear, direct, specific and one vs multishot
  • Evaluation: generating test datasets, code graders and model graders
  • Context and managing
  • Extending capabilities through skills and tool calls
  • Implementing MCP and CLI for AI access

Soft Skills

You tend not to notice the presence of these, but you do notice their absence.

  • Demonstrates continual professional practice
  • Ability to express ideas in words, Ideally succinctly. Also not overly terse.
  • Typing: a suitable speed and 97%+ accuracy
  • Terminal and use of a computer without a mouse.

Admin & Operating

These are things that are always requiring improvement and allow everyone around you to operate effciently.

  • Estimation in theory: breaking down tasks and giving realistic timelines
  • Estimation in practice: understanding your estimates are never correct and being able to handle that
  • Admin hygiene: updating tickets, writing up what you did, keeping your board current
  • Async communication: writing good PRs, commit messages, and status updates without being chased
  • Meeting participation: raising blockers, not going silent
  • Giving and receiving feedback

Version Control

Understanding more than just git branch -b and git pull origin main is essential. Sooner or later you’re going to have to rebase yourself out of a pickle.

And sometimes, trends change so knowing more than one system is an advantage.

  • Git, mercurial, subversion, jujitsu, CVS (if you know you know)
  • Workflows: gitflow, trunk based
  • Writing high quality commit messages
  • Code review: giving and receiving as a collaborative act, not just a quality gate

Computer Science

Modern languages are very convenient in that they compile down into machine instructions for you. But they still execute on a CPU and if you understand how that CPU works then you’re going to write better code. If you’re clever you’ll notice that I’ve left out memory management. I don’t currently work in any languages that require me to do that. Yet.

  • bits and bytes
  • Processor basics: cycles and bitwise operations
  • Concurrency: blocking and async operations
  • Strings: binary, unicode, ascii
  • Encoding and decoding

JavaScript / TypeScript

Listed because it’s unavoidable as an engineer in 2026. I am not a huge fan, but I can work with it.

  • Modules
  • Compiling
  • npm, pnpm
  • Different runtimes: Bun

Encryption

The web is a hostile environment. Some data needs to be encrypted at all times. You really need a solid handle on how to use (not implement, don’t ever roll your own cryptography) various types and flavours of encryption.

  • SSL
  • Private public key
  • GPG
  • AES
  • HMAC
  • JWE

Security

There’s little chance you will write software that isn’t going to be attacked. You need to know how to write secure code free of cracks that can be turned into unauthorised backdoors into your infrastructure.

  • Secure coding practices and OWASP basics
  • Dependency auditing
  • Secrets hygiene: never committing secrets, .env discipline
  • safe.env files: commit friendly environments
  • Incident response and team roles
  • vulnerability management

Compliance

At a minimum you’re going to be writing code that has duties to data protection legislation. You need to be able to translate that context to your engineering context. It is also likely that you or your customers have some aggrement on information security, cyber security and increasingly - AI security. All of which is based on the concept of risk management.

  • Risk: being able to apply pragmatic risk decisions and frameworks
  • Privacy posture: data protection legislation, privacy by design and by default
  • Security posture: secure software development lifecycle, IS27K series, SOCII, customer security documentation, paperwork and auditing evidence
  • Cyber security posture: workstation hardening, permissions, BYOD and working on locked down machines
  • AI governance: shadow AI, protecting all of the above in an age of LLM’s

Networking

Understanding how these networking technologies work is another non-negotiable. Writing an HTTP server is an excellent place to learn. When you understand how they work, you’re able to optimise for your intention.

  • HTTP
  • TCP / UDP
  • DNS

Databases / Stores

I’m guilty of not fully exploring how best to get the most out of Postgres. I’m attempting to remedy that by leveraging it more. Don’t also forget that sometimes a NoSQL datastore or specialist pattern could be the better solution.

  • SQL: PostgreSQL / MySQL
  • NoSQL: Redis, Mongo
  • Specialist datastores and patterns: Kafka, CQRS
  • Database migrations: writing safe, reversible migrations

Observability

Your code is going to fail or be sub-optimal. Having intelligence around it is essential which is why observability must be designed into your code as you work.

  • Logging: structured and searchable
  • Metrics and alerting
  • Error tracking tools: Sentry, Datadog or similar
  • Reading production signals to know your work is healthy

Deployment & Infrastructure

There will probably be an ops team. But that doesn’t mean you’re off the hook for being up on your infrastructure. You need to be able to ship code, not just write it. It also needs to be correctly packaged and defect free.

  • Containerisation: Docker, podman
  • Environment management: local vs staging vs production
  • Feature flags, rollbacks, zero-downtime deploys
  • CI / CD: Jenkins, GitHub Actions, secret management

Configuration Formats

Things need configurating and you’re the person to do it.

  • YAML
  • TOML
  • config

Writing & Documentation

Many of your technical decisions will be made asynchronously and you need to be able to be persuasive and accurate. When you’re writing up a post-mortem you need to be honest and factual.

  • RFCs and ADRs: proposing and recording technical decisions
  • Runbooks: how to operate what you build
  • Postmortems: honest, blameless write-ups of incidents

Architecture

Time changes everything. The inter-second timeframes that alter how users experience your systems and the inter-year periods that batter the consistency of your codebase. The architectural decisions you make decide the fate of your codebase.

  • Time: designing for now and the future
  • Maintainability: documentation, commenting, shared idiomatic style
  • Monolith vs Microservices
  • Caching
  • Message queues
  • Horizontal and vertical scaling

Leadership & Teamwork

Even if you don’t lead, you need to be lead-able. This is is it’s own skill.

  • Puts team before self
  • Incident participation: showing up, helping triage, not going silent
  • Onboarding others: pairing, knowledge sharing
  • Personal and professional development of you and your reports (if you have them)

Money

Financials are the backbone of a business. The technology you choose and the architecture it sits in will decide if you’re viewed as a cost centre in need of managing, or a capable profit centre who is in control of expendature vs return.

  • Cloud
  • PaaS
  • SaaS

Fin

That’s the list. Think about that surface area. It’s huge.