Abdirahman Jama, a Software Development Engineer @ AWS (Opinions are my own), recently posted something that made me stop scrolling: "My fellow engineers, take note. 👇".

It is a tiny line, but it carries a big implication: there are a few lessons that are so repeatedly expensive in engineering that they are worth calling out in public, in plain language, and without over-explaining.

So I want to do what that line invites us to do: actually take note. Below is my attempt to expand Abdirahman Jama's prompt into a practical checklist you can use this week, whether you are early-career or already leading projects.

"My fellow engineers, take note." is not motivational fluff. It is a reminder that fundamentals still beat cleverness, especially at scale.

The hidden message: fundamentals compound

When someone as busy as an AWS engineer posts a short callout, I read it as: "I have seen the same mistakes enough times that I want you to avoid them." In software, small mistakes compound:

A vague requirement becomes a week of rework.
A missing test becomes a production incident.
A poorly named function becomes a month of confusion.
A rushed design becomes a brittle system nobody wants to touch.

And the flip side is also true: small habits compound into trust, autonomy, and career momentum.

Take note of what actually moves the needle

Here are the areas I think Abdirahman Jama is implicitly pointing at, based on what consistently separates solid engineers from merely busy ones.

1) Clarity beats raw speed

If I had to bet on one skill that improves everything else, it is the ability to make your work legible to other humans.

Write things down before you code

A lightweight design note (even 10-20 lines) can prevent weeks of churn. At minimum, capture:

Goal: What problem are we solving?
Non-goals: What are we explicitly not solving?
API or interface: What will callers rely on?
Failure modes: What happens when dependencies fail?
Rollout plan: How do we deploy and roll back safely?

Fast engineering is not typing quickly. It is reducing misunderstandings.

Name things like you expect someone else to maintain them

You probably do. Even if you are the only maintainer today, future-you is someone else. Prefer boring clarity over clever names.

2) Own the outcome, not just the task

"Take note" also reads like a push toward ownership. Not performative ownership, but the kind that shows up as:

You confirm requirements instead of assuming them.
You proactively surface risks.
You measure the impact after shipping.
You notice when the system is unhealthy and you act.

A simple way to practice this is to end each week asking:

What did I ship that improved a user or a system metric?
What risk did I reduce?
What did I learn that I should share?

If you cannot answer, it does not mean you failed. It means you should adjust how you pick work, communicate progress, or define done.

3) Quality is a strategy, not a polish step

A lot of teams treat quality as "we will clean it up later." Later often never comes.

Define what done means upfront

Before coding, agree on:

Testing expectations (unit, integration, end-to-end)
Observability (logs, metrics, tracing)
Performance constraints (p95 latency, memory, cost)
Security posture (authz checks, input validation, secret handling)

When these are afterthoughts, they become incident themes.

Make the safe path the easy path

If you want quality at scale, bake it into the workflow:

Pre-commit hooks
Linting and formatting
CI that runs fast and fails loudly
Small PRs with clear descriptions

The best quality systems are the ones that make it hard to do the wrong thing by accident.

4) Communication is part of the job, not overhead

Abdirahman Jama addressed "my fellow engineers" for a reason. Engineering is a team sport.

Say the quiet part early

If you are blocked, confused, or worried about a design, say it early while change is cheap. Waiting until a deadline is near turns solvable issues into drama.

Match your update to your audience

For engineers: tradeoffs, edge cases, interfaces.
For product: user impact, timeline, risks.
For leadership: scope, dependencies, cost, confidence level.

A useful template that works almost anywhere:

Status: what is done, what is next
Risks: what could slip and why
Ask: what decision or help you need

5) Learn systems, not just tools

Tools change constantly. Systems concepts age well:

Concurrency and backpressure
Idempotency and retries
Data modeling and migrations
Caching and invalidation
Consistency models
Distributed tracing and debugging

If you invest in these, you will adapt to any new framework faster, and your designs will be calmer under load.

6) Build a reputation for being reliable

Reliability is not perfection. It is predictability.

Be honest about estimates

If you do not know, say so, then propose a plan to find out:

"I can give a confident estimate after I spike the integration for 2 hours."
"Here are the unknowns and how I will de-risk them."

Prefer small, reversible changes

Small pull requests, feature flags, gradual rollouts, and clear rollback steps keep risk manageable and earn trust.

Trust is built when people see you handle uncertainty without hiding it.

A simple weekly checklist (take note, literally)

If Abdirahman Jama's line is a prompt to pay attention, here is a practical way to convert attention into action:

One design note per meaningful change (even short).
One improvement to tests, logging, or alerts each week.
One message that reduces ambiguity (requirements, timeline, ownership).
One small refactor that improves readability.
One post-ship check: did it do what we said it would?

You do not need to do all of these at once. Pick one, repeat it, and let it compound.

Closing thought

I like how Abdirahman Jama kept it simple: "My fellow engineers, take note." That is the tone of someone who has seen the cost of avoidable mistakes and wants you to skip the pain.

If you take nothing else from this, take this: the engineers who grow fastest are not the ones who chase complexity. They are the ones who practice clarity, ownership, and quality until those traits become their default.

This blog post expands on a viral LinkedIn post by Abdirahman Jama, Software Development Engineer @ AWS | Opinions are my own. View the original LinkedIn post →