Readable is a property of today. Maintainable is a property of next week, next person, next feature. Two different questions: “Can I read this?” and “Is it safe to change this?” Judge every component by the second one.
Symptom. You can’t list what the file does in one sentence each. Handlers reference each other’s state.
Diagnosis. Run these in order. First yes wins.
Choose the lowest rung that works: function → component → hook → reducer → context → library.
Before writing any hook, run the test: does this touch React state, effects, or refs? No → it’s a plain function. Most logic doesn’t touch React at all.
Use this whenever you wall off a feature.
Symptom. Many features piled into one file. The component has a long name for what is really a collection of unrelated behaviors.
Fix. Name the features. Extract the islands first, cheapest first. Do not extract features that aren’t tangled. Walls around empty rooms are clutter. Use the extraction pass.
Found. AnnotationInput: 8 features in 395 lines. The extraction is in the ref soup recipe.
Symptom. DOM math, state logic, and JSX all in one flat function. The hardest code in the file is buried mid-function between useState calls.
Fix. Extract logic that doesn’t touch React into pure function modules. Cheap, testable, zero overhead.
Found. The caret-mirror measurement (caretContentTop, caretEdgeLines) was pure DOM math sitting inside AnnotationInput. It was already functions. The fix was moving it out with its feature, not converting it to a hook.
Symptom. Two files that are 95% identical.
Fix. One component, one variant prop. Check the sibling files first, always. The cheapest find in any codebase is duplication.
Found. SectionHeaderBroken and SectionHeaderRemoved, 95 lines each, 95% identical. Same confirming state, same outside-click effect, same handlers. Only the label and a CSS class differed. One variant prop replaces both.
Symptom. The state of one feature gets mutated by handlers of another feature. A cancel button resets three other features’ refs. You touch one feature and you have to check three others.
Cause. Nothing has walls between features, so every handler has to clean up everyone else’s mess.
Fix. Run the extraction pass.
Found. AnnotationInput: five handlers mutated three refs (prevValueRef, historyIndexRef, draftRef) that belonged to one feature. The fix was one hook, not seven. The history feature moved out with its own refs and its own DOM hack. Five call sites became method calls. The file dropped to around 300 lines and the smell was gone. Score went from 5/10 to 7/10. The drag-resize and snippet-trigger features stayed inline. They weren’t tangled.
Symptom. Flags allow combinations that can’t happen. isLoading && isError is a valid value in the type system but a lie in the domain.
Fix. Union types / discriminated unions. One status field with legal values beats five booleans. If the state has transitions (can’t cancel while saving), use a reducer with explicit transitions, not flags.
Symptom. Computed values kept in state, needing sync logic to stay current.
Fix. Derive during render. useMemo only when the computation is expensive. Sync effects are a bug farm.
Found. Sidebar computed its groups and counts during render with useMemo. That was already correct. This recipe is the target, not a failure.
Symptom. A value is set but never read in that state. You can’t trace any read of it.
Fix. Delete it. Trace the reads before the writes. If a value is never read before being overwritten, the write is dead code.
Found. After snippet select, draftRef was set to the new value, but the next read path always overwrites it from the textarea first. The write was unobservable. reset() was equivalent.
Symptom. A Set in useState. Every update is new Set(prev), mutate, return. Awkward to update immutably.
Fix. Store as a record keyed by id, or use a reducer with explicit transitions (toggle, clear).
Found. Sidebar: selectedIds as Set
Symptom. A value prop plus direct DOM writes. The framework controls the value, a handler writes the DOM node directly.
Fix. One source of truth. Route every write through the state setter. Direct DOM writes fight the framework and break silently the day a value transform or re-render guard appears.
Found. AnnotationInput’s recallHistory wrote ta.value directly while the textarea was controlled by value={value}.
Symptom. A module-level mutable singleton. Created once, appended to the document, never removed. Breaks if a second instance ever mounts.
Fix. Instance-scope it: hold it in a ref, create on demand, remove in an effect cleanup on unmount.
Found. AnnotationInput’s caretMirror: appended to document.body once, never removed. Worked only because the component never unmounted. It would leak the day it did.
Symptom. isX, isY flags piling up on props or derived internally, driving conditional markup in every branch.
Fix. Variants or composition instead of flags. When a component has real modes (normal, deleted, broken), make the mode a variant, not three booleans.
Found. EntryAnnotation: isDeleted, isBroken, expanded, selected all driving the same markup. The deleted and broken action-button groups are near-identical and duplicated across the header and expanded body. Extract the action set, compute it once from the status variant.
Symptom. Data passed down through layers of components that only forward it.
Fix. Composition first: pass the rendered element, not the data. Context only when many components at different depths need the same value. Context for everything is a trap.
Symptom. The clever stuff (time bucketing, label formatting, filtering) is trapped inside JSX or handlers. You can’t test it without rendering the whole component.
Fix. Extract pure function modules. Unit test them directly.
Found. Sidebar’s recent-groups time bucketing (“Just now”, “Today”, “This week”, “Other”) is pure logic inside the component. It belongs in a module with tests.
Makefiles, a classic way to run commands in a project. We define targets, and each target has a recipe. With this file, we run commands like make dev or make build. Simple and effective way to manage tasks in a project.
Those Makefiles are fine. But I think I found a way that fits me better.
I used Makefiles for years, like everyone else. They do what they’re for. But what they’re for is narrow: a list of targets, each with a recipe, and every recipe is a shell fragment with invisible rules around it. Tabs matter. Quoting gets weird. The moment a command needs real logic, a condition or an env check, you’re doing shell gymnastics inside a DSL that keeps getting in the way.
Now that AI is here, the last reason to stay is gone. Writing a script used to cost setup time; now my agent writes it for me. All that remains is the tool itself, and Makefile’s feature set is too restrictive to justify keeping it.
What I actually want from a task runner is simple. I want to type a short command and have the right thing happen. I want to read the file later and see every command it offers at a glance. And I want scripting flexibility when one of my commands needs real logic.
I call mine runtask. By runtask I mean a single executable Ruby file at the root of the repo. No gems, no dependencies, nothing to learn. Commands are entries in a hash, arguments get matched and dispatched, and anything complicated is just Ruby.
The part that changed how I build is not the file itself. It’s that I stopped writing it by hand.
My coding agent loads skills, small instruction files that package a pattern. I made one for this pattern, called runtask-maker. Now when I start a project I say “set up my runtask” and the agent produces the same file, in the same shape, every time. The skill is short. It holds the rules and a template:
chmod +x the filebail and run helpers, never a raw system() callThe chmod one matters most. It’s the difference between ./runtask working and a cold “command not found”.
Every runtask file has four blocks: config, helpers, commands, dispatch. Config holds the script directory and constants. Helpers load .env files and run commands with loud errors. Commands is a hash of argument arrays to lambdas. Dispatch matches your input and prints usage when nothing matches.
COMMANDS = {
%w[core dev] => -> { run "cd core && gow run ." },
%w[web build] => -> { run "cd web && npm run build" },
%w[deploy] => -> {
bail("VM_USER missing, add it to .env") if ENV["VM_USER"].to_s.empty?
run "ssh #{ENV["VM_USER"]}@vm 'docker compose up -d'"
},
}.freeze
That’s the whole surface. No phony targets, no variable plumbing, no tab rules. Two of those commands are from real projects. One of them stops before touching the server if the env is wrong. In a Makefile, that same guard is a shell script sitting inside a target.
The part I like most: run the file with no arguments and it tells you everything.
$ ./runtask
Usage: ./runtask <command>
Commands:
core dev Start Go API with hot reload
web build Build frontend for production
deploy Sync and restart services on the VM
./runtask core dev runs the command. Adding a new one is a line in the hash and a line in the usage block. That’s the whole maintenance story.
./runtask works, but the dots bugged me. make never makes you type ./make. So I added a thin wrapper to my PATH - a small shell script that just runs ./runtask in the current directory.
runtask deploy # same as ./runtask deploy, no dots
And because the command list lives in the file, completion can read it straight out of there:
$ runtask <TAB>
backup deploy pull
Add a command to the hash, and TAB completion picks it up on the next press. No separate completion file to keep in sync. The wrapper sets it all up for you:
curl -fsSL https://avrebarra.github.io/assets/runtask -o ~/bin/runtask && chmod +x ~/bin/runtask
runtask --setup # installs completion for your shell (zsh, bash, fish)
runtask --uninstall # removes everything, no trace
It writes the right completion file per shell - compinit for zsh, a marked source block in .bashrc for bash, a file in the completions dir for fish. Everything reversible with one command.
Thats how I replaced my Makefiles with a Ruby script file this week. Makefile is fine. But I think I found out that we are entitled to a better way going forward.
This is just one more stuff that made me more convinced that nowadays with AI, there’s more reason to ditch restrictive stuffs as we can get the better stuffs in a practically easier, but still more flexible, readable, and maintainable way.
This one usecase of runtask pattern is simple, but it works better. Guess what comes next?
The skill my agent loads: runtask-maker/SKILL.md
---
name: runtask-maker
description: >
Create or extend the "runtask" file - a single executable Ruby script at the repo
root that replaces a Makefile with a typed command table (`./runtask core dev`).
Use when user says "set up my runtask", "make a task runner", "add a command to
runtask", "replace the makefile with a script", "create my scripts file", "add a
deploy/dev command script", or when a project needs a Makefile and a script would
be cleaner. Backs the runtask with a copy-paste template and always sets chmod +x.
---
## runtask - the Ruby task-runner file
One executable Ruby file at repo root. Replaces Makefile. Runs arbitrary shell
commands with typed args: `./runtask core dev`, `./runtask deploy`.
Runs anywhere (macOS/Linux, no gems, stdlib only). Better than Makefile: real
language for conditionals/env checks, readable errors, no tab-sensitivity.
## When to use
- Multi-command project (dev/test/build/deploy/lint across domains) - use runtask.
- Monorepo with multiple apps → namespace commands: `%w[core dev]`, `%w[web release]`.
- Deploy/ops workflows with env checks (SSH, scp, docker compose) - use runtask.
**When NOT to use (YAGNI):**
- Single command → just run it, no file.
- Single-language simple app with package.json → use its built-in `scripts` block.
- User explicitly asks for a Makefile - don't override.
## Non-negotiable rules
1. **ALWAYS `chmod +x runtask`** after creating or copying the file. Verify with `ls -l`.
2. File name: `runtask`, no extension, repo root. (Existing projects may call it
`scripts` - same pattern, leave their name unless user asks to rename.)
3. Ruby only, stdlib only. No gems, no bundler.
4. Run via `./runtask <cmd...>` - never `ruby runtask`. Usage text must say `./runtask`.
5. Every command must be in the USAGE heredoc - file self-documents.
6. Exit codes: 0 success, 1 failure or unknown command.
7. `bail` + `run` helpers always included (see template). Never raw `system()` without error handling.
## Structure (follow exactly)
1. `#!/usr/bin/env ruby` + `frozen_string_literal: true`
2. `# ─── config ───` - `SCRIPT_DIR = File.dirname(File.expand_path(__FILE__))`, constants
3. Helpers: `load_env(path)` (parses `.env`-style files), `bail(msg)`, `run(cmd)`
4. `# ─── commands ───` - `COMMANDS` hash: array of downcase args → lambda
5. `# ─── dispatch ───` - `ARGV.map(&:downcase)` → lookup → `exit cmd.call ? 0 : 1`
or print USAGE heredoc + exit 1
Section comments lowercase, one line, no numbering (project convention).
## Template
Full skeleton: `template/runtask` in this skill dir. Copy it, edit COMMANDS +
USAGE, `chmod +x`. Command bodies use `run "..."` (prints + bails on failure)
or lambdas with `bail(...)` for preconditions (env vars, files, SSH reachability).
## Conventions
- Commands lowercase. Namespaced pairs for monorepo: `%w[core dev]`, `%w[web release]`.
- Secrets/env → `.env` at repo root, loaded by `load_env`. Never hardcode.
- `.env` stays gitignored. `load_env` silently skips missing file - no crash.
- Multi-step command → `run` each step, print `>>>` progress lines, end with status.
- Long helper output (e.g. cron hints) → print as `#`-prefixed comment block.
## Example
```ruby
COMMANDS = {
%w[dev] => -> { run "npm run dev" },
%w[deploy] => -> {
bail("VM_USER not set - put it in .env") if ENV["VM_USER"].to_s.empty?
run "ssh #{ENV["VM_USER"]}@vm 'cd app && docker compose up -d'"
},
}.freeze
```
The template it generates: template/runtask
#!/usr/bin/env ruby
# frozen_string_literal: true
# ─── config ──────────────────────────────────────────────────────────────────
SCRIPT_DIR = File.dirname(File.expand_path(__FILE__))
def load_env(path)
return unless File.exist?(path)
File.readlines(path).each do |line|
line = line.strip
next if line.empty? || line.start_with?("#")
key, value = line.split("=", 2)
ENV[key.strip] = value.strip.delete(%q('"))
end
end
def bail(msg)
warn "❌ #{msg}"
exit 1
end
def run(cmd)
puts " $ #{cmd}"
bail("#{cmd.split.first} failed") unless system(cmd)
end
load_env("#{SCRIPT_DIR}/.env")
# ─── commands ────────────────────────────────────────────────────────────────
COMMANDS = {
# %w[dev] => -> { run "npm run dev" },
# %w[test] => -> { run "npm test" },
# %w[core dev] => -> { run "cd core && gow run ." },
}.freeze
# ─── dispatch ────────────────────────────────────────────────────────────────
input = ARGV.map(&:downcase)
cmd = COMMANDS[input]
if cmd
exit cmd.call ? 0 : 1
else
puts <<~USAGE
Usage: ./runtask <command>
Commands:
dev Start dev server with HMR
test Run tests
USAGE
exit 1
end
The wrapper that makes it feel native: assets/runtask
#!/bin/sh
# runtask - bare `runtask <cmd>` runner + one-command completion setup
# install: curl -fsSL https://avrebarra.github.io/assets/runtask -o ~/bin/runtask && chmod +x ~/bin/runtask
# setup: runtask --setup [zsh|bash|fish]
# uninstall: runtask --uninstall
set -u
say() { printf '%s\n' "$*"; }
# ─── command parsing ─────────────────────────────────────────────────────────
runtask_cmds() {
grep -o '%w\[[^]]*\]' ./runtask 2>/dev/null \
| sed 's/%w\[//; s/\]//' \
| awk '{print $1}' \
| sort -u
}
# ─── completion bodies ───────────────────────────────────────────────────────
zsh_body() {
cat <<'EOF'
#compdef runtask ./runtask
# complete runtask commands by parsing %w[...] definitions from ./runtask
_runtask() {
local -a cmds
if [[ -r ./runtask ]]; then
cmds=(${(f)"$(grep -o '%w\[[^]]*\]' ./runtask | sed 's/%w\[//; s/\]//' | awk '{print $1}' | sort -u)"})
fi
compadd -- $cmds
}
_runtask "$@"
EOF
}
bash_body() {
cat <<'EOF'
# bash completion for runtask - parse %w[...] commands from ./runtask
_runtask() {
local cur cmds
cur="${COMP_WORDS[COMP_CWORD]}"
cmds="$(grep -o '%w\[[^]]*\]' ./runtask 2>/dev/null | sed 's/%w\[//; s/\]//' | awk '{print $1}' | sort -u)"
COMPREPLY=( $(compgen -W "$cmds" -- "$cur") )
}
complete -F _runtask runtask
EOF
}
fish_body() {
cat <<'EOF'
# fish completion for runtask - parse %w[...] commands from ./runtask
complete -c runtask -xa '(grep -o "%w\[[^]]*\]" ./runtask 2>/dev/null | sed "s/%w\[//; s/\]//" | awk "{print \$1}" | sort -u)'
EOF
}
# ─── install helpers ─────────────────────────────────────────────────────────
add_marker() { # add_marker <file> <block-file>
file=$1
block=$2
strip_marker "$file"
printf '\n# runtask:start\n' >>"$file"
cat "$block" >>"$file"
printf '# runtask:end\n' >>"$file"
}
strip_marker() {
file=$1
[ -f "$file" ] || return 0
awk '/^# runtask:start$/{skip=1} !skip{print} /^# runtask:end$/{skip=0}' "$file" >"$file.tmp" || true
mv "$file.tmp" "$file"
}
install_zsh() {
zdir=${ZSH_CUSTOM:-"$HOME/.oh-my-zsh/custom"}
mkdir -p "$zdir/completions"
zsh_body >"$zdir/completions/_runtask"
say "zsh: wrote $zdir/completions/_runtask (auto-loaded by compinit)"
}
install_bash() {
bdir=$HOME/.bash_completion.d
mkdir -p "$bdir"
bash_body >"$bdir/runtask"
rc=$HOME/.bashrc
block=$(mktemp)
printf '[ -d "$HOME/.bash_completion.d" ] && for f in "$HOME"/.bash_completion.d/*; do [ -r "$f" ] && . "$f"; done\n' >"$block"
add_marker "$rc" "$block"
rm -f "$block"
say "bash: wrote $bdir/runtask + source block in $rc"
}
install_fish() {
fdir=$HOME/.config/fish/completions
mkdir -p "$fdir"
fish_body >"$fdir/runtask.fish"
say "fish: wrote $fdir/runtask.fish (auto-loaded)"
}
# ─── setup / uninstall ───────────────────────────────────────────────────────
setup() {
shell=${1:-}
[ -n "$shell" ] || shell=${SHELL##*/}
case "$shell" in
zsh) install_zsh ;;
bash) install_bash ;;
fish) install_fish ;;
*) say "runtask: unsupported shell '$shell' (zsh|bash|fish)" >&2; exit 1 ;;
esac
}
uninstall() {
rm -f "$HOME/.oh-my-zsh/custom/completions/_runtask" 2>/dev/null
rm -rf "$HOME/.bash_completion.d" 2>/dev/null
rm -f "$HOME/.config/fish/completions/runtask.fish" 2>/dev/null
strip_marker "$HOME/.bashrc"
say "runtask: removed completion files + rc markers"
}
# ─── dispatch ────────────────────────────────────────────────────────────────
case "${1:-}" in
--setup) setup "${2:-}" ;;
--uninstall) uninstall ;;
--help|-h)
say "runtask - bare \`runtask <cmd>\` runner with one-command completion setup"
say " runtask <cmd...> run ./runtask in current dir"
say " runtask --setup [shell] install completion (zsh|bash|fish)"
say " runtask --uninstall remove completion + rc markers"
exit 0 ;;
*)
if [ -r ./runtask ]; then
exec ./runtask "$@"
else
say "runtask: no ./runtask here" >&2
exit 1
fi
;;
esac
I’m skeptical of how that gets interpreted.
AI does generate fast, that part is not in dispute. Across writing, code, research, and imagery, the pace advantage is real. Content that took hours takes minutes. Code drafted in an hour. Research summaries, articles, analyses, volume is no longer the constraint.
But speed of generation is not the same as capacity for governance.
As AI tools absorb more of the production work, the human role shifts toward reviewing, validating, and curating, not creating. That sounds like progress. It isn’t, not automatically. The shift created a new accountability, one most have not yet picked up.
The bottleneck has moved from production to comprehension.
The pressure AI creates runs almost entirely in one direction: produce more, faster. Articles accumulate. Codebases grow. Research outputs multiply. Images proliferate. What doesn’t accelerate is the work of reviewing, shaping, and pruning what no longer belongs, or never should have been produced in the first place.
AI-generated output, across domains, tends to be:
None of this makes AI tools less useful. It makes human oversight more load-bearing than ever before.
We once produced everything we later reviewed. That symmetry is gone. AI can generate in an hour what takes days to fully evaluate. That gap opened while people were celebrating the speed. Most are still not looking at it.
Quality is the minimum condition for human oversight to function. In code: readability, structure, modularity. In writing: accuracy, coherence, original voice. In research: rigor, citation integrity, sound reasoning. The properties that make a body of work navigable at speed, whatever the domain.
When these properties hold, anyone can move through a body of work quickly enough to actually govern it. They can identify where things don’t fit. They can see what is accumulating. They can make the call to prune. The human stays responsible.
When they break down, none of that works at the pace AI demands. If the output cannot be reasoned about, the human in the loop becomes decorative.
Maintaining quality reduces cognitive effort, enhances transparency, and lowers the cost of every intervention that follows:
These are not quality metrics. They are the mechanisms by which we retain meaningful control over a body of work that now grows faster than any one person can produce. And the same AI capability accelerating generation can be turned toward this too, catching drift, flagging redundancy, surfacing what no longer belongs. The leverage works in both directions.
When AI makes generation this fast, it is easy for effort to concentrate entirely there. Generation is visible, rewarding, immediate. Oversight is slower and harder to justify. The risk is that the imbalance grows quietly, until the output becomes too large to govern.
Maintaining quality is no longer primarily about the next person who picks up where we left off. It is about whether we can still see what is happening inside a system, or a body of work, that AI is actively accelerating.
Maintaining, shaping, pruning: these become even more primary tasks.
The practical path is not to resist the speed. It is to redirect some of that same capability toward governance. Generate fast. But hold the responsibility. Use AI on both sides, production and oversight, so the pace is sustainable, not just impressive.
The gap between what AI can produce and what we can still govern is where quality is decided now.
]]>In the golden days of microservices hypes, while most of us were hyping up toward microservices, I decided to actively refactor back into a monolithic architectures. I was technically questionied at first of this but I go on. Then things changed: we went from a team working over the nights to a team with zero works past 4PM for two years. We deliver all business-requests fast. We donned strategic initiatives for fun. We even started helping up other teams’ backlogs.
From that one decision, I learned that: dropping teams workload should always be core targets.
Let’s go back to the regressive-sounding decision I made: my team was a small 4-person squad responsible for governmental projects. We frequently faced sudden development requests with urgent deadlines. People were asking us to create an E2E mobile app from scratch integrating with 4 national banks within <20 working days (this actually happened; and please mind Indonesian banks are bureautically slow). You can imagine the pressure we were giving to ourselves spinning up multiple services every time a project came up. That’s why handling lots of microservices was not for us. Switching to a monolith was to make things simpler, help us deliver faster. The strategy worked wonders in the long run with our next big government projects.
But let me be clear: this isn’t about advocating for monoliths over microservices. Not about being rad and going against the current. The core principle is about leaning things up, removing current states that doesn’t serve your team’s specific context and constraints, and in the process, reducing engineers workload.
Whether that means consolidating microservices into a monolith, simplifying deployment pipelines, reducing the number of tools in your stack, or streamlining processes, the goal is the same: eliminate overheads that prevents your team from doing things agile-ly. (TODO: write about this) I argue that simplifying work processes shouldn’t be something that requires extensive justification. Leaning up processes should be as northstar as gaining more revenue. It should not require sophisticated business justification. It’s a just common sense.
You might think that the direction I’m going with this post is about work-life balance. While that’s part of it, the real benefits of reducing manpowers workload go far beyond just avoiding manpower burnout.
When manpowers aren’t constantly firefighting or context-switching between fragmented systems, they unlock cognitive space for meaningful work. This isn’t just about work-life balance, it’s about creating conditions where people can actually excel at what they do.
Sustainable workloads create space for continuous learning. Manpowers can stay current with technologies, explore new patterns, and make informed architectural decisions. This isn’t just professional development, it’s competitive advantage through better technology choices.
Manpowers with capacity remain agile when priorities shift or emergencies arise. An underutilized manpowers isn’t wasted, they’re prepared for opportunity. At LinkAja, this agility meant handling urgent government pilots while maintaining core product quality.
Optimized workloads enable consistent high performance over months and years rather than unsustainable sprints. When people feel sustainable in their work, they bring full creative capabilities to problems, writing code that works elegantly and extensibly.
Customers don’t care about development processes, they care about product quality and reliability. But overworked manpowers create technical debt, introduce bugs, and make rushed decisions that compound over time, directly impacting user experience.
When development teams operate with optimized workloads, the benefits flow directly to end users in measurable ways:
Manpowers with adequate cognitive bandwidth write more defensive code, consider edge cases, and implement proper error handling. They have time to write comprehensive tests and conduct thorough code reviews. This translates to fewer production outages, reduced downtime, and more stable user experiences.
Teams operating at sustainable capacity also can respond to critical issues immediately without derailing existing work. When manpowers aren’t already at 100% utilization, they have the mental clarity to diagnose problems quickly and implement proper fixes rather than temporary patches that create future issues.
Features built by well-rested manpowers are more intuitive, performant, and user-friendly. Manpowers have time to consider the user journey, optimize performance, and polish interactions. They can iterate on designs based on user feedback rather than shipping the first working version due to time pressure.
When development teams aren’t firefighting constantly, they can allocate resources to address customer feedback quickly. Feature requests get proper evaluation, bugs get prioritized appropriately, and improvements ship on predictable schedules.
The result? More reliable products, faster feature delivery, and better user experiences. Customers benefit from the downstream effects of sustainable development practices, even when they’re unaware of the engineering processes that enable them. They simply experience products that work consistently, features that make sense, and support teams that respond quickly to their needs.
Some might raise up a question “Things are already going fine. What we are freeing capacity for? Aren’t we just paying people to do less?”
I would say that is a very misconception. Leaning the process just to free up workload is not wasting money. We always need to have free capacity. Capacity is not waste. Capacity is a strategic asset. To do things. To plan things. To actually figure out what to do if we are having free capacity.
Optimizing manpowers workloads isn’t just a “nice to have”, it’s a strategic business decision that drives measurable financial benefits. While it may seem counterintuitive to reduce what we are making the manpowers do, the reality is that this is actually a practice that will win in the long run.
Rushed stuffs created from a bad working environment generates maintenance overhead that compounds like financial interest. It especially come back faster in a fast iterating business like software businesses. Every shortcut taken under pressure becomes a future tax on development velocity. Technical debt doesn’t just slow down feature delivery, it creates hidden operational costs through increased debugging time, more production incidents, and expensive refactoring cycles.
Teams with sustainable workloads write cleaner code initially, reducing long-term maintenance costs by 30-50%. This isn’t perfectionism, it’s fiscal responsibility.
When manpowers aren’t overwhelmed with firefighting, they can engage meaningfully with business objectives. They understand customer needs, contribute to product strategy, and make technical decisions aligned with business goals.
This deeper involvement creates better products because engineers who understand the “why” build solutions that truly serve users and business needs. They catch misaligned requirements early, suggest alternative approaches that save development time, and architect systems that support business growth rather than constrain it. (TODO: write about this)
Replacing a burned-out senior engineer costs 6-12 months of their salary in recruitment, onboarding, and lost productivity. A $120K engineer costs $60-120K to replace, not including the knowledge loss and project delays. Sustainable workloads prevent this expensive churn cycle.
Organizations with optimized manpowers workloads report 40-60% lower turnover rates in engineering teams. The savings compound: reduced recruitment costs, less onboarding overhead, and retained institutional knowledge that prevents repeated mistakes.
Teams with optimized workloads also achieve the same output with fewer people or deliver significantly more value with existing teams. This isn’t about layoffs, it’s about resource efficiency. A team that can deliver the same results with 20% fewer engineers or 20% more features with the same headcount creates direct cost advantages.
This efficiency multiplies across the organization. When one team demonstrates that sustainable practices enable higher per-person productivity, it creates a template for scaling without proportional hiring increases. Companies can grow revenue without linearly scaling engineering costs, improving unit economics and profitability.
While competitors burn through talent delivering rushed features, organizations with sustainable practices build systems that compound in value over time. This creates durable competitive advantages through:
At LinkAja, my squad’s optimized workload didn’t mean reduced productivity, it meant surplus capacity that demonstrated organizational strength rather than resource waste.
I think we needs to start accepting workprocess leaning (a.k.a lessening workloads) as a strategic action. We need to constantly put creating conditions where people can consistently do their best work, as our top priority along with other business purposes. When teams have breathing room, it opens up capacity, we can get strategic. We can solve harder problems. We build systems that last.Not about being soft on performance or lowering standards.
Everyone wins when manpowers workload drops strategically. The challenge isn’t proving this works, the results speak for themselves when you try it. The real challenge is shifting mindsets in cultures that still believe more hours equals more value.
The best way to go faster is: to always have a space to find out about how we can go faster.
]]>When working with Go functions that accept multiple parameters, there’s an interesting approach we can explore: using struct parameters instead of positional arguments. This technique can bring clearer code and structure to our function interfaces, especially as complexity grows.
Struct parameters offer an alternative approach where, instead of passing a long list of positional arguments, we pass a single struct containing all the necessary data. This becomes especially helpful when functions start to require many parameters, sometimes five, six, or even more, leading to unwieldy signatures like:
func CreateUser(name, email, age int, isActive bool, role string) error {
// implementation
}
// Usage - with several parameters, it's easy to lose track of what each value means
err := CreateUser(
"John",
"john@example.com",
30,
true,
"admin",
)
As the number of parameters grows, it becomes increasingly difficult to keep track of what each value represents, making the code harder to read and maintain.
type CreateUserParams struct {
Name string
Email string
Age int
IsActive bool
Role string
}
func CreateUser(params CreateUserParams) error {
// implementation
}
// Usage - struct parameters provide much clearer context
err := CreateUser(CreateUserParams{
Name: "John",
Email: "john@example.com",
Age: 30,
IsActive: true,
Role: "admin",
})
The struct approach makes the code more self-documenting, as field names provide immediate context about what each value represents. This can be particularly valuable during code reviews, where reviewers can quickly understand the intent and spot any potential issues more easily. The built-in documentation aspect is another benefit - struct fields can include comments and tags, giving us better IDE support with autocomplete and parameter hints.
However, this approach does introduce some additional overhead. We need to define structs for each function, which means more boilerplate code. There’s also a learning curve as the team adopts these new patterns, and we need to maintain consistency in struct naming and conventions across the codebase. Of all, one notable downside of struct parameters is that, because struct fields have zero values by default, all parameters become effectively optional. This can unintentionally allow incomplete or invalid data to slip through, unlike positional parameters where required arguments are enforced by the function signature.
This challenge, though, can be addressed by introducing explicit validation logic for the struct fields, turning this potential pitfall into an opportunity for more robust input checking, as discussed in the next section.
This is where struct parameters become particularly interesting, they naturally encourage better validation practices. By using struct parameters, we can take advantage of Go’s struct tags to define validation rules directly on each field. This enables us to leverage popular libraries like go-playground/validator/v10 for declarative, reusable validation logic.
Struct tags make it easy to specify constraints such as required fields, length limits, or format checks, keeping validation rules close to the data they apply to. This approach can also significantly reduce the amount of repetitive if statements you need to write for manual validation, leading to cleaner and more maintainable code.
import (
"fmt"
"github.com/go-playground/validator/v10"
)
var validate = validator.New()
type CreateUserParams struct {
Name string `validate:"required,min=2,max=50"`
Email string `validate:"required,email"`
Age int `validate:"required,min=18,max=120"`
IsActive bool `validate:"-"`
Role string `validate:"required,oneof=admin user guest"`
}
func CreateUser(params CreateUserParams) error {
if err := validate.Struct(params); err != nil {
return err
}
// implementation
return nil
}
Implementing more frequent validation brings several advantages. Following the fail-fast principle, we can catch issues at the entry point rather than deep in the logic, providing clearer and more actionable error messages. This approach also helps prevent invalid data from propagating through the system, making debugging much more straightforward since we know exactly where validation failed.
Additionally, frequent validation acts as a safeguard against unexpected or malformed input from external users or systems. By validating inputs early, we reduce the risk of downstream errors and ensure that only well-formed data enters our core logic, improving the overall reliability and security of our applications.
With positional parameters, the compiler can enforce that all required arguments are provided, offering a form of static validation at compile time. In contrast, struct parameters make all fields optional by default, so missing or invalid data is only caught at runtime through explicit validation. While this shifts some safety checks from compile time to runtime, the risk is manageable if the module is using the validation correctly plus already well covered by unit tests. As long as validation logic is thoroughly tested, the benefits of clearer code and maintainability usually outweigh this trade-off.
*Params suffix for parameter structsStruct parameters combined with frequent validation create a robust foundation for maintainable Go code. While there’s an initial investment in setup and learning, the benefits of clearer code, better error handling, and improved maintainability typically outweigh the costs.
The key is to start small - try this pattern with new functions first, and gradually refactor existing code where it provides clear value. Remember that the goal is better code quality and developer experience, not just following a pattern for its own sake.
]]>We naturally think sequentially when we code―it feels intuitive, it’s easy to reason about, and it works. We write functions that call other functions, handle one task after another, and build our applications step by step. This sequential approach serves us well in most programming languages where concurrency comes with significant overhead and complexity.
But in some languages that support concurrency, like Golang, concurrency is cheap and accessible, making it almost wasteful to stick with purely sequential execution, especially when our code could genuinely benefit from doing multiple things at once.
When we have operations that don’t depend on each other, like fetching data from different APIs, processing independent files, or making multiple database queries, we’re leaving performance on the table by doing them one after another.
Consider a typical scenario in a web application where we need to fetch data from multiple sources to build a response. The straightforward approach often looks like this:
func GetDashboardData(ctx context.Context, userID string) (*DashboardData, error) {
profile, err := userService.GetUserProfile(ctx, userID)
if err != nil {
return nil, err
}
transactions, err := transactionService.GetRecentTransactions(ctx, userID)
if err != nil {
return nil, err
}
notifications, err := notificationService.GetUnreadNotifications(ctx, userID)
if err != nil {
return nil, err
}
return &DashboardData{
Profile: profile,
Transactions: transactions,
Notifications: notifications,
}, nil
}
This approach is clear and easy to understand, but it has a significant drawback: each operation must complete before the next one can begin. If each service call takes 100ms, our total response time is at least 300ms, even though these operations are completely independent of each other.
func GetDashboardData(ctx context.Context, userID string) (*DashboardData, error) {
g, ctx := errgroup.WithContext(ctx)
var (
profile *UserProfile
transactions []*Transaction
notifications []*Notification
)
g.Go(func() error {
var err error
profile, err = userService.GetUserProfile(ctx, userID)
return err
})
g.Go(func() error {
var err error
transactions, err = transactionService.GetRecentTransactions(ctx, userID)
return err
})
g.Go(func() error {
var err error
notifications, err = notificationService.GetUnreadNotifications(ctx, userID)
return err
})
if err := g.Wait(); err != nil {
return nil, err
}
return &DashboardData{
Profile: profile,
Transactions: transactions,
Notifications: notifications,
}, nil
}
With this concurrent approach, all three operations run simultaneously. Our total response time becomes the duration of the slowest operation rather than the sum of all operations, potentially reducing our response time from 300ms to just over 100ms.
While we could achieve concurrency using raw goroutines and channels, errgroup provides several advantages that make it the preferred choice for this pattern:
The errgroup automatically cancels the context when any goroutine returns an error, causing all other operations to be cancelled as well. This prevents unnecessary work and ensures fast failure detection.
The errgroup.WithContext() function creates a derived context that gets cancelled when the first error occurs, allowing all goroutines to respond appropriately to cancellation signals.
No need to manually manage channels or wait groups, the Wait() method handles all synchronization logic and returns the first error encountered, if any.
The performance benefits of concurrent execution become more pronounced as the number of independent operations increases or as the latency of individual operations grows. Here’s how the math works:
// Sequential Timing
Operation A: 100ms
Operation B: 150ms
Operation C: 80ms
Total: 330ms
// Concurrent Timing
All operations start simultaneously
Total: max(100ms, 150ms, 80ms) = 150ms
This represents a 55% reduction in total execution time, a significant improvement that users will notice, especially in latency-sensitive applications.
It’s important to recognize when and how to apply concurrency with errgroup. Not every problem benefits from parallel execution, but for the right scenarios, errgroup can dramatically simplify your code and boost performance. Below are some practical patterns and best practices for using errgroup effectively in real-world Go applications.
This is the most common use case, where you need to gather data from multiple sources that don’t depend on each other.
g, ctx := errgroup.WithContext(ctx)
var data1, data2, data3 SomeType
g.Go(func() error { /* fetch data1 */ })
g.Go(func() error { /* fetch data2 */ })
g.Go(func() error { /* fetch data3 */ })
if err := g.Wait(); err != nil {
return err
}
// Use data1, data2, data3
When you have a collection of items that can be processed independently:
g, ctx := errgroup.WithContext(ctx)
for _, item := range items {
item := item // Capture loop variable
g.Go(func() error {
return processItem(ctx, item)
})
}
return g.Wait()
For scenarios where you want to limit the number of concurrent operations:
// Create a semaphore to limit concurrency
semaphore := make(chan struct{}, maxConcurrency)
g, ctx := errgroup.WithContext(ctx)
for _, item := range items {
item := item
g.Go(func() error {
semaphore <- struct{}{} // Acquire
defer func() { <-semaphore }() // Release
return processItem(ctx, item)
})
}
return g.Wait()
While errgroup helps mitigate many concurrency risks, there are still important considerations:
Ensure that any shared variables are properly protected. In the errgroup patterns shown above, each goroutine writes to a different variable, avoiding race conditions.
Be mindful of resource consumption. Running too many concurrent operations can overwhelm databases, APIs, or network connections. Use the limited concurrency pattern when needed.
Since errgroup returns only the first error encountered, ensure your error messages provide enough context to understand which operation failed.
The errgroup package offers a practical and reliable way to add concurrency to Go applications, reducing complexity compared to managing raw goroutines and channels directly. By identifying independent operations, especially those involving I/O or external services, you can often achieve significant performance gains with minimal code changes.
To get started, begin by reviewing your code for sequential tasks that don’t rely on each other. Where appropriate, use errgroup to run them concurrently, improving responsiveness and resource utilization. With careful application and attention to best practices, errgroup can help you write faster, more maintainable, and robust Go programs.
Pinjol debts and financial chaos used to sound like background noise, stuff that happened to “other people” for me. Lately, though, those headlines are landing closer; it’s friends, neighbors, people I know.
I’m kind of surprised, well, not really, but it hits me that it’s closer than I thought. I’ve been hearing stories of people struggling, and pardon me for judging but I can’t help but think maybe it has something to do with how they live. Like wanting to live big. Like maybe we’re chasing too much. Or maybe I’m wrong. I don’t know. But it makes me think lately.
I get it, people want to feel alive. We want joy, fun, excitement. And yeah, what is life if it’s not lively, right? But I’m starting to question what “lively” really means. Social media kind of screws with our heads. It makes anything less than flashy look like failure. We all know, that’s messed up.
Lately I start to think that maybe what makes lives lively are just about the margins, the gaps. What makes life memorable are those gaps between moments. Like that time we went from meh 😒 to WOWZA 🤩. That’s one of life isn’t it? Those changes of feelings, those gaps.
Now I kinda think, sure, those going ups give us gaps, that sweet contrast. But maybe it’s also okay to not endlessly chase the higher and higher gaps. Maybe we don’t need to live life like we’re always chasing highs just to feel like we’re living. Living below our means, embracing the downs too, maybe that’s how we last. We can still enjoy the ups when they come, but we don’t have to gain something every day. We’re earthlings. The sky is vast, limitless, but we’re bound by how long our limbs can hold us up to keep our head over the ground. We can jump, true. But let’s not recklessly catapult ourselves into the atmosphere.
I’m the kind of person who finds peace in things that others might call mundane (wn: oh how self righteous it makes me sick too haha, but bear with me). I think people around me also knew that I can be very boring. Heck I am so boring. I stare at leaves. I lie on the floor and look at clouds moving, for tens of minutes. I sit alone in a supermarket corner eating snacks like it’s a ritual. I swim by myself. I motorbike around aimlessly and talk to myself. I can stay on a place for the whole day without talking to anyone or laughing along or listening to anything. That is a boring person by definition ain’t it? Sometimes I even wonder to myself too―wah, is this really me? just this? nothing fancy to show off?―and at times it made me feel a little feeble too. Ain’t I look miserable? Like maybe I need to live more?
But lately, I’ve started to feel grateful for this kind of life. I’m glad that it makes me content. I’m not saying it’s the right one. I’m not trying to self-justify. But this demeanor, this plainness, has quietly kept me safe from some of the risks people around me are currently facing. At least for now. Alhamdulillah ala kulli haal. Or maybe I just got lucky? Or still got lucky? I don’t know. I’m not advocating to live like me. I don’t even know if this is good for me in the long run. But if nothing else, maybe hey use me as lower baseline! As reminder that there are people like me, who live pretty boring lives, and (can survive trying to) being content with it.
So please live below means, live boring.
No, I take that back. Just put it in mind as a possible way to take, to live below means and boring. Trying to keep up with those crazy, flashy standards by spending beyond what we can afford is not a good idea―and no, ability to pinjol and lendings aren’t counted as what we can afford. Be boring and don’t be reckless. It’s okay to humble things down sometimes, we’ll still live. Maybe without those crazy adrenalines, but still living, still breathing. We’ll still feel things. Not social media worthy, but we’ll still have moments.
If you worry about being seen as simple or boring, sneer at me, or sneer at someone else like me… no, sneer at me. Use us as your lower baseline. Even if you live a plain, quiet life, there’s at least one person in your circle with even more boring life. And that’s okay.
Just don’t get caught up in those problems for that reason, will you? Because I overthink a lot, and damn I wish I never have to overthink about you too.
]]>Hello again, and HAPPY NEW YEAR! Feliz Ano Novo!
May all our wishes come true this year!
Reflecting on 2023, it was quite a rollercoaster, as some friends experienced significant ups and downs. A friend who was once struggling with suicidal thoughts unexpectedly turned joyful and better. One marriage turned against each other due to a simple miscommunication, leading to irreparable consequences not because of the problem itself but due to their reactions. Another new marriages, another fistfights, another event failed miserably, and some football competitions. It was wild.
As for me? To be frank 2023 for me stands out as the best year since like 2018, in term of self-fulfillment.
From 2018 to years after, sure I did got career and skill improvements in those years, but honestly life felt empty and boring especially during the COVID years with bad health and habits. I don’t really learn anything new those years so yeah life felt kinda boring like we’re just being floating in a shallow slow current.
In 2023 though, in Q4, I decided to take a fresh start, jumping into the unknown sea. Which probably transaltes to people and swimming pool haha. I saw many dramas arose. Some are pretty bitter and emotional dramas, but seeing back into those boring years, somehow I find the bitterness are kinda refreshing haha. All in all, I can say I’m happy with 2023.
To those who faced challenges in 2023, keep pushing through. The tech winter and numerous layoffs may have impacted families, but I hope you regain everything and bounce back even stronger.
While I don’t see New Year as a massive milestone (tbh its just another Q4 to another Q1), but it’s still a new empty page flipped upon us.
Let’s take a pen.
Let’s write many good things on this page.
PS. I really intended to write a technical article, but alas the New Year greeting sway me a detour wkw
]]>Looking back, it was a very long deliberate heavy thinking back then that brought me into this decision. It’s a difficult decision, there are some less pleasant aspects to it, but overall, I’m quite satisfied with what I’ve gained in exchange.
During this free time, I’ve embarked on activities I couldn’t pursue due to work commitments: learning swimming, playing guitar, reading, writing, reconnecting with old friends, exploring AI/ML, and even trying mountaineering.
Just recently, I was appointed as a Youth Leader at the local mosque. It revolves around making young lads and lass to go to mosque to pray and learn Quran and Hadist and such.
In this break, with all these free times I have, I found myself getting more involved in this role. This and that, not so long after, I realized one thing: The work I do as leader now is kinda more easier than before I took a break.
A little context on what the old conditions were: previously, everything felt like a solitary effort, which is fine because it’s actually did not come with demanding tasks. But I can’t say that I hoped some different results on this leadings. Things were quite time taxing. I can get things done but honestly feel like I’m working by myself all the time. I took some team decision, in various way, but not many are really committed to it. Things are going good but I honestly think it could be better. However, upon my break, everything feels smoother, I can really feel people backing me.
It initially puzzled me, but when I traced back, I’ve come to understand the clear significance of something I hadn’t done before.
Yes, duh. I just, treated people more like people. I spent time together and wasted time together. Honestly aren’t that much hassle and tbh I could’ve also did it before I had a break. But I admit it was totally different than when I first took on the leadership role. My approach was: Let’s make this youth group member more systematic and tidy, creating procedures and helping members learn various skills. I wanted the organization to function smoothly even in my absence. Just like what I did at my professional work. I organize I taught people ideas I delegate things. That is idealistic notion. That never materialized.
But when I started spending more time together its just that I can kinda see the rewards are splattered around me.
Today I’ve come to realize again the basic that people are just, well, people. Unlike machines, everyone have their own dynamics and desires. Previously, I thought I could organize the organization like I did in my professional life, treating people (which includes me) as nodes in our big big machine, which worked pretty well without a problem (probably because thats pretty normal in the field).
However, in this nonprofessional sector, where motivations are not solely driven by payroll, where things are felt more raw, pure, and honest, this approach is flawed. People are really people; they are unique individuals with their own motivations and desires that I have to get closer to get to know.
This small realization will be some nail in the wood for me. Affirming some ideas that actually was already there but not really seen clearly. To not treat people as just dots, just functions providing predictable outputs based on inputs. That they have their own dynamics, reasons, and motivations, which may not always align with what we expect.
In professional world, individuals often can function flawlessly as if they were a cog in a machine. However, we must acknowledge and respect the human aspect, considering their needs, plans, and desires. Although abstration of organization as an abstraction has its merit, we have to know that it probably just a facade, of a pure and honest organization where humans are actually needed to be treated as human. Whoa, beautiful.
Mind it, I was a shy anxious introvert that never really involved in leadership before my professional experience in leadership. All these small things are small things but still funny to me, considering how I experienced formal leadership before the non-formal one. It’s kinda late, but I’m very grateful for these new perspectives mending events.
Revisiting back the title, in conclusion, my break has again fortify me a valuable lesson: to lead and organize people, it’s essential to still embrace their humanity. Recognizing and respecting individual dynamics, motivations, and desires creates a more harmonious and fulfilling environment, leading to greater success in our collective endeavors.
If I have to take one quote: the magic will happens when we treat all people as unique individuals. Then, let’s.
]]>Ever been driven frustrated by something seemed simple, only to discover hidden complexities beneath?
I’ve been on quite a journey myself. Let’s dive into my experiences on building what I called an onion system.
Back in my Bukalapak days, loyalty points system was one of projects I have to work on. The mission was clear: process transactions asynchronously and calculate the loyalty points. The core system would send a signal to our microservices, and we’d evaluate and whip up some loyalty points for customer.
Being a newbie, we thought simple - we thought loyalty points were our one and only big word there. Not too big scope, all figured out. So we jumped right in and developed that async system with some database, backend, and RabbitMQ for messaging. We had issues, we fixed, the task was completed and running without major hiccups. But there was a nagging feeling - something was off with the system layout I know, but I couldn’t quite understand what was it.
Fast forward to LinkAja. Again here I had to cook up another async system. Prakerja bulk-async fund disbursement system. A hot government program at that time.
This time, it was like playing in the big leagues. This system is a big system planned to involve billions Rupiah circulated everyday. High traffic. High reputational stake.
At start, we analyzed and I thought, “It’s all about ‘funds’ again, right? Just like what I did back then and add some bulk inputs.” We split the work over several sprints, trying to ensure progress step by step. And as usual, there are changes on the middle of work, nothing unexpected. We thought.
But boy, the challenge was huge. Somehow every minor requirement requires boatload of adjustment all over the codebase. It felt like a struggle to make things developing incrementally. Feels like we lost progress for every changes coming.
It’s a shaky design. I don’t want to rely on this ticking timebomb, I said.
So we retook a deep dive on the design. The grand revelation hit us: bulk-async-disbursement system wasn’t a solo act; it was a three-layered system. After analysis we found the lining of three different system involved: a disbursement system, wrapped up by an async system, and then bundled inside a bulk processing system.
Treating them as one was like trying to detangle a knotted mess. Each piece had its role, but put in another’s piece, and when one went awry, it felt like trying to fix a jumbled orchestra. That’s when we knew we did it wrong and we have to fix the abstractions ground up. The interconnectedness was so intricate that untangling one piece without pulling apart everything proved to be quite the challenge.
So in short, we sprinted and tried to construct the new abstraction. Splitting one work into three works. Renegotiating timelines. Reexplaining the work scopes.
We built those subsystems:
And as expected, everything fell into place. Developments ran smoothly, progress tracked accordingly, bug fixes are blisses. When we stepped back to admire our handiwork, we realized yep it was a giant.
We couldn’t help but chuckle at our previous audacity, thinking we could squeeze it into a tiny box.
This story taught us one cool lesson. You gotta look beneath the surface and not be fooled by the ‘sweet’ single-domain facade. Don’t judge a system just by its name. Sometimes, that one sweet domain dances with unnamed but funky mechanics. Here I was talking about bulk and async. But you have to be aware too about things like data encryptions, notification, content management, or event publishing acrobatics.
Even if a system looks like a neat package with a single entry and exit, it might be an onion - layers upon layers. So, don’t shy away from peeling those layers and revealing the complexities within. This wisdom is your secret weapon when you face future complex systems. Stay sharp and don’t underestimate what’s under the hood.
You could be looking at one intricate onion.
]]>