VP of Engineering · Engineering & leadership notes

Most engineering decisions aren't really about the technology.

They depend on the team, the expectations, and the tradeoffs people are willing to state openly. These are short, opinionated notes on leading software teams.

Read the notes LinkedIn GitHub Email
21
notes published
2024 – 2026
Feb 2024 to Nov 2026
9+ years
leading engineering teams
UTC+7
Yogyakarta, Indonesia

Latest notes

Featured Risk An automated check that can fail silently is worse than the rule it replaced Read the note
  1. No. 21 · Nov 2026 Communication A number without an expiry date is a rumour, not a measurement Dashboards and status updates show the latest value and let the reader assume it is current. A reading that carries the time it stops being true cannot be mistaken for one that is merely the last thing somebody wrote down.
  2. No. 20 · Oct 2026 Security A dependency pinned to a URL has no maintainer unless you name one When a library leaves the package registry, pointing at the vendor's download link looks like the same dependency from a different address. It is a different arrangement, because the registry was quietly doing a job for you, and that job now needs an owner.
  3. No. 19 · Oct 2026 Security When a credential is the feature switch, whoever handles secrets decides what ships Gating a new capability on whether its API key is present is tidy: no flag, no ceremony, one variable and it's on. But it quietly moves the decision to adopt from the person accountable for it to whoever is copying environment files that day.
  4. No. 18 · Sep 2026 Code Quality Don't chase a green scorecard — make "failed, with a reason" a passing state A score rewards the colour, so the cheapest way to raise it is to delete whatever is failing. A failure someone chose on purpose, with the reason written down, is the only thing that keeps a score worth reading a year later.
  5. No. 16 · Aug 2026 Delegation Draw the autonomy line at what's reversible, not at what's risky Risk is a judgment call, so it gets re-made badly or skipped entirely. Reversibility is a property of the action itself — and it gives the same answer every time.
  6. No. 15 · Aug 2026 Code Review Cap the optional findings in a review — the ranking is the contribution An uncapped review lists everything it noticed, which trains the author to skim. A cap forces the reviewer to rank, and the ranking was the part worth reading.
  7. No. 14 · Jun 2024 Prioritization Across many projects, the task that unblocks others outranks the one that's merely urgent Value and urgency rank tasks one at a time. Dependencies change the math — finishing an unblocker multiplies everyone else, which a per-task score never captures.
  8. No. 13 · Jun 2024 Communication Explaining an algorithm well is translation, not simplification Simplifying means throwing accuracy overboard until it's easy. A good analogy carries the real idea across to someone without the vocabulary — and keeps it intact.
  9. No. 12 · May 2024 Risk When a client wants risky tech fast, the assumption to test first is that they need it A push for rapid adoption smuggles in a premise — that newer is better. Honoring the timeline starts with a focused risk check on the premise itself.
  10. No. 11 · May 2024 Security Remote data security is a set of defaults, not a set of rules A rule asks every person to remember to do the secure thing. A default makes the secure thing the only thing that happens — and only the second kind survives a distributed team.
  11. No. 10 · May 2024 Growth Keeping up with technology is a consistency problem, not a time problem People wait for a free afternoon that never arrives. Thirty minutes every few days, reliably, outruns the big study block you keep postponing.
  12. No. 09 · May 2024 Stakeholders Don't reject an unrealistic request — re-price it Saying no to a user spends goodwill and ends the conversation. Naming the cost and offering an alternative keeps both the relationship and the constraint intact.
  13. No. 08 · Apr 2024 Tooling Language debates only end when you anchor them to the project, not the person A team arguing over favorite languages is having an unwinnable argument. Re-framing it around what the work actually requires turns preference into a decidable question.
  14. No. 07 · Apr 2024 Collaboration When designers and developers deadlock, a prototype settles what a meeting can't A meeting lets two strong opinions re-litigate each other indefinitely. A proof of concept converts the argument into something you can observe.
  15. No. 06 · Apr 2024 Code Quality Under deadline pressure, automated standards beat agreed-upon ones A coding guideline everyone agreed to relies on discipline — the first thing pressure burns through. A linter doesn't get tired or behind schedule.
  16. No. 05 · Apr 2024 Remote Teams Including a remote team in decisions means designing the moments they can show up Cameras-on meetings build connection — and quietly exclude whoever's in the wrong time zone. Real inclusion needs a path that doesn't depend on being awake at the same time.
  17. No. 04 · Mar 2024 Architecture An architecture migration is mostly archaeology on the system you're leaving Migration plans obsess over the destination. The risk lives in the origin — the undocumented, half-supported legacy system whose authors have left.
  18. No. 03 · Mar 2024 Technical Debt Technical debt is invisible work — so the job is making it visible The hard part of managing debt isn't the refactoring. It's convincing the people who can't see it that paying it down is worth as much as a feature they can.
  19. No. 02 · Mar 2024 Stakeholders Inviting stakeholders in is only half the job — managing expectations is the other half Bringing stakeholders into backlog refinement builds buy-in, but it quietly raises a promise you can't always keep.
  20. No. 01 · Feb 2024 Tooling Choose tools for the team you have, not the team you wish you had The team's existing familiarity is the most underrated input into a tooling decision — but comfort can also become a trap.

About

VP of Engineering at Polyrific, leading a distributed team across Indonesia, the Dominican Republic and the US.

Client projects are mostly .NET on Azure and data platforms; our own products run on Node and TypeScript. The stack varies, the decisions around the code don't — review standards, delegation, stakeholder expectations, and how teams adopt agentic coding.

If a note here reads wrong from where you sit, I'd like to hear why.

Also writing in Bahasa Indonesia: C# Indonesia Practical notes on modern C#/.NET and agentic coding, from real projects. Visit