Abdirahman Jama recently shared something that caught my attention: "I'm a software engineer at AWS with 7+ years of industry experience. Here are 17 lessons I've learned along the way" followed by a punchy list starting with "Titles don't equal impact" and "Write code for humans first." I have reread those lines a few times because they capture what many of us learn the hard way: the craft of software engineering is less about cleverness and more about clarity, trade-offs, and responsibility.

What I like about Abdirahman Jama's post is that it reads like notes from the field, not a textbook. So instead of just repeating the list, I want to respond to it and add the context that makes each lesson actionable when you are building real systems with real users.

Impact beats optics (and titles)

Abdirahman Jama opens with a reminder that deserves to be printed and taped above a monitor:

"Titles don't equal impact."

In practice, impact is measurable outcomes: fewer incidents, faster onboarding, lower cost, happier customers, clearer roadmaps. Titles can help you get in the room, but impact is what keeps you there. If you want a simple self-check, ask: "If my title disappeared tomorrow, would my teammates still feel the value I create?"

Another line that pairs naturally with this is:

"Understand the business, not just the tech."

Business context is not corporate fluff. It is how you decide what to simplify, what to automate, and what to leave alone. A beautifully engineered feature that does not move a metric or unblock a customer is still a miss.

Write for humans, then let the machine run it

Abdirahman Jama's second point is foundational:

"Write code for humans first."

Code is read far more often than it is written. "Humans first" means naming things well, designing small interfaces, leaving a trail of intent, and making the next change cheaper. A few practical moves:

Prefer boring, explicit control flow over clever one-liners.
Design APIs that are hard to misuse.
Optimize for the reader who is tired, new to the codebase, or on-call.

This connects to another of his lessons:

"Document decisions - context fades over time."

Documentation does not have to be a novel. A short decision record that explains "what we chose, what we rejected, and why" can prevent months of re-litigation. The key is to document the decision, not just the implementation.

Become the go-to, but stay flexible

Abdirahman Jama wrote:

"Be the go-to person for something."

This is career advice disguised as engineering advice. Teams run on trust, and trust comes from repeated proof in a domain: observability, performance, payments, deployment, data modeling, security, or even a specific service.

But there is a trap: becoming "the only person" for something. The sustainable version of "go-to" is: you build the system, you teach the system, and you reduce the team dependency on you over time.

That idea shows up later in his list too:

"As you grow, help others grow too - pay it forward."

Mentorship scales your impact and makes the team resilient.

Trade-offs, simplicity, and the art of not coding

Two of Abdirahman Jama's lessons sit at the center of good engineering judgment:

"Everything is a trade-off."

and

"Some problems can be solved without code."

If you want to ship more and suffer less, get comfortable with the non-code solutions: changing a process, clarifying requirements, deleting scope, buying a managed service, or even saying "no" with evidence.

His next points reinforce a design philosophy that many high-performing teams share:

"The simplest design that works usually wins."

Simplicity is not laziness. It is choosing the smallest set of moving parts that meets the real needs. Complex systems do not just cost more to build. They cost more to understand, test, operate, secure, and change.

If you have ever been the person debugging a multi-hop, over-abstracted system in production, you will appreciate his very real warning:

"You'll regret complexity when you're on-call at 2AM."

A useful heuristic: complexity should be introduced only when it pays rent. If a design does not clearly improve reliability, velocity, or cost at the scale you actually have, it is probably premature.

Build in passes: run, right, fast

Abdirahman Jama includes a classic triad:

"Make it run, make it right, make it fast."

I like this because it gives permission to iterate while still demanding professionalism. "Make it run" is about validating the path and learning quickly. "Make it right" is where you add tests, improve design, handle edge cases, and confirm you are meeting the real requirements. "Make it fast" is last because performance work without measurement is often wasted effort.

This also pairs with:

"Don't fall in love with your code - it'll be rewritten."

Rewrites happen because requirements change, scale changes, or the original assumptions were wrong. If you treat code as a temporary tool rather than a personal artifact, you will design for change: clean boundaries, migration plans, and data safety.

Operate what you build: observability and root causes

Abdirahman Jama nailed two operational truths:

"You can't operate what you can't observe."

and

"Fix the root cause, not just the symptom."

Observability is not just "add logs." It is a coherent story of signals: metrics for health, logs for details, traces for causality, and alerts tied to user impact. If you cannot answer "what is broken, who is affected, and what changed" within minutes, your system is effectively opaque.

Root-cause thinking is what turns incidents into progress. Symptom fixes stop the bleeding. Root fixes stop the recurrence. The practical pattern is:

Contain the incident.
Identify contributing factors (technical, process, and communication).
Implement preventative changes (tests, guardrails, automation, limits).
Share learnings broadly.

His point that "Production systems are the best teachers" is true because production is where all assumptions meet reality: traffic spikes, partial failures, dependency limits, bad inputs, and human error.

Run toward the fire, and stay human

Two lines from Abdirahman Jama's list feel like a philosophy for long-term growth:

"Run towards the fire - this is where you grow the most."

and

"Be a good human - this scales more than technical skills."

The "fire" is the hard work: incidents, migrations, hairy legacy systems, ambiguous requirements, and cross-team conflicts. Volunteering for those problems accelerates learning because you are forced to build judgment, not just features.

And being a good human is not a soft add-on. It is the multiplier: clear communication, calm during incidents, generosity with credit, rigor without ego, and empathy for users and teammates. Teams with psychological safety fix issues faster and share context more freely, which is exactly what you want when stakes are high.

A practical checklist inspired by the 17 lessons

When I translate Abdirahman Jama's post into day-to-day behavior, I end up with a simple checklist:

Can I explain the business goal and the trade-offs in plain language?
Is the design the simplest thing that works at today’s scale?
Did I avoid code when a process or product change solves it better?
Is the system observable enough to operate under stress?
Did we capture the decision context so future us can move faster?
Am I building other people up, not just shipping my own work?

If I can answer "yes" consistently, I am likely creating the kind of impact that outlives any title.

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 →